2023-09-12 11:56 AM
Hi all
I tried to implement a tcp echo client application in evaluation board,here I can able to send and receive the data through the tcp socket.am running a tcp echo server from Linux . Whenever am sending data greater than 1460(MSS) am receiving more than 1 packet in client side.
suppose am sending 3000 bytes from server side it send the data in 3 packets and need to poll nx_tcp_receive function 3 times to read the data from the queue. Need to receive the entire 3000 data at once is there any method available in Netx to implement this.
am taken the tcp echo client example code from st. (Do I need to enable ip fragmentation feature in order to avail this requirement if yes kindly help )
with regards
2023-09-12 12:07 PM
>>Need to receive the entire 3000 data at once..
Why? You don't get to dictate the packet limits on the network segments between your nodes. TCP allows for in-order and successful recovery of the larger data block, but expect that you might need to own some of the reconstruction. If you've ever had to do file/data management where the data exceeds the available memory, you should have no problem wrapping your head around this, and you might come up with a solution that scales better.
2023-09-13 07:03 AM
here am using TCP echo client application code from ST.
am using nx_tcp_socket_send and nx_tcp_socket_receive for TCP sending and receive operation.from server side when am sending 3000 bytes of data its splitting into 3 packets and send to client so here am getting the entire data in the receive queue.so from here do in need to reassemble the packet manually or is there any option available in netx for that.
segement or packet size is not a concern for me , the ultimate aim is to get the proper amount of data send from server and send it to my application.
2023-09-14 12:17 AM - edited 2023-09-14 12:19 AM
TCP provides a data stream, not a data messages! The underlying TCP segments, IP fragments (not recommended) and Ethernet MTU doesn't matter here. The TCP cannot reassemble your messages because a stream has no concept of beginning/end. And, as it is a stream, the delivered chunks have no guarantees for specific sizes and/or arrival times. Also take a note that the nx_tcp_socket_send() function is not guaranteed to succeed, including because of NX_WINDOW_OVERFLOW error, and consider using the nx_tcp_socket_receive_notify() callback for a decent software architecture, where the reception can be cancelled when necessary.