CODEWITHSUNDEEP
socketsunixtcp
user1055568
user1055568

Reputation: 1429

tcp read() immediately after accept()

If I call send() immediately after synchronous connect() returns on the client side, is it reasonable to expect that calling read() immediately after accept() on the server side will return the first segment of data? I.e., will a client receiving the SYN-ACK typically wait a bit to see whether there is any payload to include on the ACK completing the 3-way handshake?

The first message in my protocol will include an authentication token (< 500 bytes), so was thinking it would be handy to synchronously read() and validate immediately after accept(), and close the socket if not valid. Otherwise, it seems like I need to have some state tied up waiting for asynchronous time out. I will be dealing with a limited set of common client platforms, so not concerned about theoretical possibilities across all TCP implementation.

Upvotes: 1

Views: 333

Answers (2)

user1055568
user1055568

Reputation: 1429

The answer is no in general, but Linux offers TCP_DEFER_ACCEPT socket option, which means accept() does not return until data has arrived. In that case, read() immediately after accept() should return data.

Upvotes: 1

o11c
o11c

Reputation: 16016

No.

Even if you could rely on well-behaved clients, in network problems it is almost never safe to rely on anything happening reliably like that.

Also, when you're using unencrypted data, all sorts of intermediate routers will think its their business to muck with the data.

With UDP the problem is actually simpler, though obviously you have to implement your own reliability and congestion-control algorithms.

Upvotes: 1

Related Questions