Hi Aaron
As long as you set a socket to listening state it should be prepared for any following connection request (a request will only result in a RST when there is no listening socket on the TCP port in question - meaning that the socket's state is not suitable for accepting a connection). Therefore I can't explain any delays in a following attempt. If you send me a Wireshark recording (to email address) I may be able to see something which explains why it is not immediate.
Back to the 2MSL topic: First of all it should be noted that, according to the TCP specification, a TCP server should not accept any connections for a period of 2 minutes after first being
turned on. This is in fact the same as 2MSL after ending a connection since the thinking is that a server may have been rebooted during or just after a connection and so also shouldn't accept a connection on a previously used socket within the same time period. PC TCP stacks don't respect this because generally it takes more than 2 minutes to boot up anyway....but the question is whether embedded stacks, which are ready to operate as soon as the Ethernet has auto-negotiates (say 3 or 4 seconds) should stay in a "silent" mode for two minutes? I think that the question is superfluous since most complaints heard about embedded systems is why they are not ready in less that these 3 or 4 seconds!
Since the 2MSL time is protecting against something that will (especially today with fast Internet) hardly take place and also if does will result in a TCP RST being sent back it does seem justified to accept a deviation from the word of the specification in preference of better embedded operation. It can also be disabled so that no connection is possible for minutes if this needs to be performed...
Therefore I would suggest that there is generally no problem in setting a socket which has just closed immediately back to the listening state. It allows one socket to be used for connections which close and are then immediately opened again.
It is also possible to reserve multiple sockets for use by a single TCP connection. This can be done in two ways:
- either like the HTTP which has a number of sockets listening and can handle multiple connections in parallel - these are called HTTP sessions and each session has its own resources so that the parallel operation is really possible. As long as there is a socket listening (meaning free for use) a further connection can take place
- or by having only one of the possible sockets actually listening at a time, in which case they share the call back and only one set of resources (eg. variables used during a connection) is needed. Also only one connection is possible at a time. The reason for having multiple sockets is that the 2MSL could indeed be respected by allowing the closed socket to stay in that state for a further 2 minutes and bridge this time by setting the next available socket to the listening state. It would thus be possible to have several sockets timing out in the 2MSL phase while there is always a fresh one immediately made available for use by a subsequent connection. The limit is of course the number of connections and closes possible within the 2MSL period since this would be the number of sockets that need to be reserved to handle the worst case. If the number is low it could be a valid technique, if high it may result in a waste of memory resources - again a mixture of the two would work . if the second strategy does lead to a situation where all available sockets are in the 2MSL phase the oldest could still be forced to listening state (as emergency measure).
fnTCP_Connect() is the inverse of
fnTCP_close(). It actively starts a TCP connection by sending a SYN to the TCP port at the remote IP address. I will add this as next job. It is not the same as
fnGetTCP_Socket() which reserves the socket for subsequent use;
fnGetTCP_Socket() is usually called only once.
SOCKET_STATE_INVALID During the documentation process I realised that some return values were not giving full information (often a failure was simply -1 and in one case a 0 was returned in error case which could not be distinguished from a value USOCKET number). These error cases generally only occur when the system is not configured correctly - for example the application tries to use more sockets that reserved, or there is not enough heap for the configuration to be established and so don't occur randomly during operation. Due to this I decided that it would be best to also improve this situation by adding some more meaningful return values - in addition documenting the non-specific return values would also have been difficult to do...
This explains why do don't find this new define. The return is still there but the define has been optimised. I have sent you (email) my working versions of
TCP.c and
tcpip.h so that you can either use them immediately or have them as reference during this phase. They will then be included in the next release so that the doc and code fully corresponds.
Regards
Mark
- fnTCP_Connect() added at
http://www.utasker.com/docs/CodeDoc/fnTCP_Connect.htm
