We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Greetings,
Intro: I am developing a TCP Server (TCP Passive Open) using LPC2364 (ARM7TDMI). I need to transmit/ receive approximately 35 Kb of data through an active TCP connection. As per document references, the TCP_MAXSEGSZ macro defines the maximum size of the packet transmitted in a single transaction. The possible range that can be defined is between 536 to 1460 bytes.
Issue: Even if I configure the maximum value 1460 as the Maximum segment size(TCP_MAXSEGSZ ), I am able to transmit only 554 bytes through an active connection.
I also came across the statement of Keil that the Maximum Segment size will be negotiated during initial handshake of the TCP connection. But the TCP client I am communicating with, is a Linux based system which has a minimum value of 4096 as Maximum Segment Size.
How can I solve this issue?
Requirement: I need the Maximum Segment size during transmission to be at least 1024 (1Kb).
Kindly help me out in this regard. Thanks in advance.
Pratheep k said:I need (sic?) the Maximum Segment size during transmission to be at least 1024
Why do you "need" that ?
I am developing a micro-controller based product/device (TCP server) where this 35kb of data has to be received and stored in another place. I don't have enough buffer space to store this 35kb in the controller. So my methodology is to divide the data into smaller packets, receive one packet, store it, send custom ACK and then receive another, store it and send custom ACK. This cycle repeats till the end. So, in this method if I have nearly 0.5kb as my maximum segment size, i'll have to make 70 transactions, which is time consuming and not reliable. So I wish to have atleast 1kb as my maximum segment size which would be much more efficient. Kindly guide me to a solution.
Just a side note to the reply from Kevin. Since you are using ARM7 based LPC2364, you are probably not using MDK middleware pack, instead you are probably still using the old RL_TCPNet library. If this is the case, the "patch" mentioned in http://www.keil.com/support/docs/3846.htm won't work for you, since the function net_tcp_get_mss() has different name and implementation in the old RL_TCPNet library. But anyway the "patch" is not really recommended, because TCP is really a "handshake" protocol, and the Tx MSS should be decided and announced by the remote node. Thus, the right way to fix this issue is really to check the reason on your remote node, why it only accepts 554 bytes.
Thank you - Andy Neil, Kevin, ChenTang. Kevin, I used the patch which you mentioned. But as ChenTang has quoted, it didn't wok for the LPC2364. Iam using the old RL_TCPNet library. ChenTang, I agree with the method to know the reason why it is restricted to 554 bytes. So, I changed the TCP client device. I used a Windows based software "TCP test tool". Even with this tool the restriction persists. So, I assume that the issue is in the micro-controller (LPC2364) side. I have quoted all the configurations I have made for the TCP connection. Kindly have a look and thanks in advance for your extended support Andy Neil, Kevin. ChenTang.
// </e> // <e>TCP Sockets // ============== // <i> Enable or disable TCP Sockets #define TCP_ENABLE 1 // <o>Number of TCP Sockets <1-20> // <i> Number of available TCP sockets // <i> Default: 5 #define TCP_NUMSOCKS 1 // <o>Number of Retries <0-20> // <i> How many times TCP module will try to retransmit data // <i> before giving up. Increase this value for high-latency // <i> and low_throughput networks. // <i> Default: 5 #define TCP_MAXRETRY 5 // <o>Retry Timeout in seconds <1-10> // <i> If data frame not acknowledged within this time frame, // <i> TCP module will try to resend the data again. // <i> Default: 4 #define TCP_RETRYTOUT 4 // <o>Default Connect Timeout in seconds <1-600> // <i> Default TCP Socket Keep Alive timeout. When it expires // <i> with no TCP data frame send, TCP Connection is closed. // <i> Default: 120 #define TCP_DEFTOUT 120 // <o>Maximum Segment Size <536-1460> // <i> The Maximum Segment Size specifies the maximum // <i> number of bytes in the TCP segment's Data field. // <i> Default: 1460 #define TCP_MAXSEGSZ 1460 // <o>Receive Window Size <536-65535> // <i> Receive Window Size specifies the size of data, // <i> that the socket is able to buffer in flow-control mode. // <i> Default: 4380 #define TCP_RECWINSZ 4380 /* TCP fixed timeouts */ #define TCP_INIT_RETRY_TOUT 1 /* TCP initial Retransmit period in sec. */ #define TCP_SYN_RETRY_TOUT 2 /* TCP SYN frame retransmit period in sec. */ #define TCP_CONRETRY 7 /* Number of retries to establish a conn. */
you might use the wireshark software to see where exactly this "554 bytes" limit comes from.
Understood. I'll try that and revert back. Thanks.
.
Thank you Andy Neil. Will be sure to follow the method.
To clarify when we talk about MSS. There are two MSSs in the TCP socket, a local receiving MSS and a remote receiving MSS.
TCP_MAXSEGSZ 1460 is the local receiving MSS on LPC2364. Linux has its own receiving MSS. It is not clear which MSS is the problem. I assume it's on Linux.