pending connections from same source

Hi,

What happens if there is a pending connection on a server and a client
connects to the server with the same source address (address and port) ?
Is the connection dropped or enqueued ?

Thanks in advance.

- Daniel.

Daniel Lezcano <(E-Mail Removed)> writes:

> What happens if there is a pending connection on a server and a client
> connects to the server with the same source address (address and port)
> ?

The TCP/IP implementation on the source should make sure this doesn't
happen (we are talking about TCP, right?). So I guess you are talking
about the case when things are broken?

> Is the connection dropped or enqueued ?

Check the state machine on page 23 of RFC 761. If sequence numbers
match, it will just retransmit SYN ACK, but if it doesn't it isn't
clear to me what will happen. I suspect that it can be specific to
each implementation.

--
Jacob

Jacob Bunk Nielsen wrote:
> Daniel Lezcano <(E-Mail Removed)> writes:
>
>
>>What happens if there is a pending connection on a server and a client
>>connects to the server with the same source address (address and port)
>>?
>
>
> The TCP/IP implementation on the source should make sure this doesn't
> happen (we are talking about TCP, right?). So I guess you are talking
> about the case when things are broken?

Yes, right, I forgot to specify TCP/IP.
>
>
>>Is the connection dropped or enqueued ?
>
>
> Check the state machine on page 23 of RFC 761. If sequence numbers
> match, it will just retransmit SYN ACK, but if it doesn't it isn't
> clear to me what will happen. I suspect that it can be specific to
> each implementation.

Mmmh, ok. But the case I tried to describe is a client connecting to a
server, sending data, closing the connection, reconnecting with same
source addresseort. The server doesn't accept the connection at the
application level (because it is busy for example) and it is the TCP
layer which accept these connections asynchronously. What should happen
with the second connection ?

Daniel Lezcano <(E-Mail Removed)> writes:

> Mmmh, ok. But the case I tried to describe is a client connecting to a
> server, sending data, closing the connection, reconnecting with same
> source addresseort. The server doesn't accept the connection at the
> application level (because it is busy for example) and it is the TCP
> layer which accept these connections asynchronously. What should
> happen with the second connection ?

So we are talking about thinks happening i the following order (C for
client, S for server):

C -> S: SYN
C <- S: SYN ACK
C -> S: ACK
.... exchanging data
C -> S: FIN
C <- S: FIN ACK
C -> S: ACK
C -> S: SYN
....

And then you wonder what will happen now? The server might still be
working on the data transmitted to it on the first connection, but the
underlying TCP implementation has closed the first connection.

In this case the server TCP implementation will accept the connection
performing the 3 way handshake and just wait for the server
application to call accept() and start reading from the socket. Check
accept(2).

--
Jacob

On Wed, 12 Apr 2006 14:26:47 +0200, Daniel Lezcano wrote:

> The server doesn't accept the connection at the
> application level (because it is busy for example) and it is the TCP layer
> which accept these connections asynchronously. What should happen with the
> second connection ?

I'm not sure what you mean by "server" above. The actual server process
(ie. the software which performed the listen())? I'd not think that the
new connection would be completely set up until the server process
performed the accept(). So I'm having trouble understanding the first
sentence cited above.

But since the first connection has been completely shut down, it doesn't
exist. This second connection is treated as if it were completely new.

- Andrew

Jacob Bunk Nielsen wrote:
> Daniel Lezcano <(E-Mail Removed)> writes:
>
>
>>Mmmh, ok. But the case I tried to describe is a client connecting to a
>>server, sending data, closing the connection, reconnecting with same
>>source addresseort. The server doesn't accept the connection at the
>>application level (because it is busy for example) and it is the TCP
>>layer which accept these connections asynchronously. What should
>>happen with the second connection ?
>
>
> So we are talking about thinks happening i the following order (C for
> client, S for server):
>
> C -> S: SYN
> C <- S: SYN ACK
> C -> S: ACK
> ... exchanging data
> C -> S: FIN
> C <- S: FIN ACK
> C -> S: ACK
> C -> S: SYN
> ...
Yes.

>
> And then you wonder what will happen now? The server might still be
> working on the data transmitted to it on the first connection, but the
> underlying TCP implementation has closed the first connection.

No the server has not accepted the first connection. So I wonder what
will happen to the second connection ? How the TCP layer will react ?

Andrew Gideon wrote:
> On Wed, 12 Apr 2006 14:26:47 +0200, Daniel Lezcano wrote:
>
>
>>The server doesn't accept the connection at the
>>application level (because it is busy for example) and it is the TCP layer
>>which accept these connections asynchronously. What should happen with the
>>second connection ?
>
>
> I'm not sure what you mean by "server" above. The actual server process
> (ie. the software which performed the listen())? I'd not think that the
> new connection would be completely set up until the server process
> performed the accept(). So I'm having trouble understanding the first
> sentence cited above.

Shortly, an application doing: socket, bind, listen, poll(0,0,-1)

>
> But since the first connection has been completely shut down, it doesn't
> exist. This second connection is treated as if it were completely new.

I am observing a different behavior, the first connection is accepted by
the TCP layer and stays as a minisock socket, the second connection is
accepted but the listen point becomes stuck: no more data can arrive and
all incoming connection (from different source address) stay in
SYN_RECVD state.

Any clues ? Is this a bogus behavior ?

On Wed, 12 Apr 2006 16:33:40 +0200, Daniel Lezcano wrote:

> I am observing a different behavior, the first connection is accepted by
> the TCP layer and stays as a minisock socket, the second connection is
> accepted but the listen point becomes stuck: no more data can arrive and
> all incoming connection (from different source address) stay in SYN_RECVD
> state.

The second connection is being created after the first has completely shut
down? Because it sounds like the server process isn't sitting in poll()
awaiting new connections (or, more accurately: is never performing the
accept() for some reason). But that's just a guess on my part.

- Andrew

Andrew Gideon wrote:
> On Wed, 12 Apr 2006 16:33:40 +0200, Daniel Lezcano wrote:
>
>
>>I am observing a different behavior, the first connection is accepted by
>>the TCP layer and stays as a minisock socket, the second connection is
>>accepted but the listen point becomes stuck: no more data can arrive and
>>all incoming connection (from different source address) stay in SYN_RECVD
>>state.
>
>
> The second connection is being created after the first has completely shut
> down?
Yes.

> Because it sounds like the server process isn't sitting in poll()
> awaiting new connections (or, more accurately: is never performing the
> accept() for some reason).

Yes, exact. It is blocked by a poll(0,0,-1) in order to avoid any accept
by the application. It is the TCP mechanims I don't understand.