Re: [tcpm] SYN/ACK Payloads, draft 01

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Ananth,

Anantha Ramaiah (ananth) wrote:
>  
>> |
>> | int newsocket = accept(...)
>> | getsockopt(newsocket, SOL_TCP, &tcpsa, ...) if (TCP_SADATA_REQ & 
>> | tcpsa.tcpsa_flags) {
>> |    // The first data from the socket is the client's 
>> draft-agl handshake
>> |    decode_tagged_data(newsocket);
>> |    ...
>> | } else {
>> |    // No special case,
>> |    continue_as_normal();
>> | }
>>
>> I'm wondering why an implementation in user space would 
>> expect to find out anything about a TCP connection that 
>> hadn't finished handshaking, i.e., the accept call above 
> 
> This has been done in some stacks today (like ours). The incoming SYN is
> reported to the application and the application can suggest whether or
> not to accept the connection. If the application gives a nod, proceed
> with the 3 way handshake else send an RST. 

Does the app have access to the SYN options? If so, that seems outside
the scope of what TCP should be exposing to the app.

> This is different from a 3
> way handshake happening (which involves the TCB and the associated
> baggage creation) and then informing the application and applications
> can reject this connection during accept(). Applications wishing to use
> this special property would set a socket option indicating the
> notification of SYN when the listener is created.
> 
> The advantage is that you don't allocate the memory ahead of time if the
> application isn't interested in accepting this connection.

It seems to me the app already sufficiently controls this in how/when it
issues a accept(). On what basis is it making the rejection at the time
of a SYN? (if by IP address, it could have done this via a different
listen() call).

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiuAdsACgkQE5f5cImnZruSpQCg0vbiE19/XHuJZAs4vICD8PLV
swQAoO0gK+GeCcjlJWSOuB8/6gjlneHY
=Hnvo
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm