[e2e] Best practise modification in TCP transition diagram?

[Mikael.Latvala at nokia.com]

Hello,

Very recently I got involved in an argument where a collegue of mine claimed that there were no good reasons why a process could not use a passive socket to create a connection to another process. Having done programming in different UNIX environments I remembered clearly that any such attempt was always denined by the underlying TCP/IP implementaion ("Address already in use"). But for some reason I had never sat down and questioned the motivation behind this restriction. 

So I went back to rfc793 and sure enough, there is a transition from LISTEN to SYN SENT when an application wants to send data (i.e. the spec allows a process to create a connection to a peer process from a port at which another process is waiting for connection requests). However, in R. Stevens UNIX network programming, vol 1, 1998, this transition has been removed.

This made me wonder if this restriction is some common practise that has become a defacto standard over times. Personally I can see only one reason why this transition is not supported. Lets assume that a process A wants to listen at a socket which is bound to port P1 and IP address A1, and some moment later needs to create an active socket, bind it to P1/A1, and establish a connection to process B at P2/A2.  If process B while waiting connections request at port P2/A2 wants to also to create a connection from P2/A2 to process A at port P1/A1 at the same time, a proper TCP implementaion on both ends should create only one TCP connection. 

The problem is: with which socket this connection should be associated with. If both ends associate it with the active socket, there is a situation that two clients are talking to each other although in reality a client functionality should communicate with the server functionality. Things don't get any better if the connection is associated with the passive sockets.

Therefore the only meaningful solution would be to associate the connection with a passive socket in one end and with an active socket in the other end. For the active socket which was not associated with the connection, TCP/IP stack would return EISCONN.  However, how do the nodes determine which side should do what? Unless a modification is added to the TCP connection establishment procedure, I cannot see a way how the nodes could agree on which side the connection is given to the server functionality and on which side to the client functionality.

One could of course modify the implementation so that in each such case the TCP/IP stack sends RST to the peer, and returns ECONNRESET to the process. Then it would be up to the client application to determine what to do next. E.g. application protocols where this kind of behaviour is expected (e.g. SIP), could specify that when a client receives RST it should wait some time (randomly chosen) before trying to reestabslih the connection.

Any comments?

/Mikael