RE: " You shouldn't have to set anything. The system should copy the TOS (DSCP) bits from the original SYN to the new 'eager' socket, so they should be there when you accept." Alas, its uglier than that. There are some emerging applications where for various reasons the DSCP bits are being re-used for policy decisions through firewalls. Today, when a DSCP-marked SYN comes in, the SYN/ACK gets sent back out without echoing the bits and thus never gets through the firewall and the connection attempt therefore fails. Ugly. So not only would it be nice if the TOS bits could be copied into the new socket on accept(), the should also (at least optionally) be echoed at handshake time. -d
-----Original Message----- From: James Carlson [mailto:[EMAIL PROTECTED] Sent: Thursday, March 08, 2007 8:30 AM To: David McDaniel (damcdani) Cc: [email protected] Subject: Re: [networking-discuss] Basic question re timing of SYN/ACK David McDaniel writes: > My *really* basic question is, given an open tcp socket to which a syn > is delivered, is the responding syn/ack sent only when the application > does an accept() ? No. The kernel does this automatically *before* the application gets a chance to do accept(). > The corrolary question is whether the server end has a means to > access the DSCP bits in the original SYN. The idea being to then > set the bits on the listen()-ing socket and ten do the > accept(). Which, if you take the man page literally would copy > that property to the new socket. No. That wouldn't work for a large number reasons. A big one is that it'd fall over with multithreaded applications and with ones that share a single listening socket among multiple processes via fork(). You shouldn't have to set anything. The system should copy the TOS (DSCP) bits from the original SYN to the new 'eager' socket, so they should be there when you accept. I think you're basically talking about "lazy accept." I don't think any modern Unix-like sockets-using system supports that feature. Also, TLI/XTI hints at it with its message-passing conventions, but it's actually never worked that way. (Google around for 'lazy accept' to see a number of discussions about it.) -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
