PHWinfo - Afficher un message - Re: For performance, one socket or two with dedicated send/receive?

12/03/2006, 18h27

In article <slrne128gf.l1l.dmfh@llanfaethlu.dmfh.cx>, DMFH <dmfh@n0spam.dmfh.cx.spamn0t> writes:
>
> Thinking back in this thread to using a single TCP socket instead of
> multiple ones for performance, this thread reminds me of the URG
> flag in TCP, and how (from my own experience) this was never quite used
> or implemented in a useful way and how it might have ed out moving
> control elements of a communication faster than content.

(The following is assuming I'm remembering the semantics of URG
correctly; I'm on a trip and don't have all my resources handy. No
doubt I will be corrected where I'm wrong.)

Urgent data doesn't get delivered to the receiving host any faster -
it's just an indication that there's special (notionally out-of-band)
data further ahead in the stream. "Further ahead" is allowed to be
after the data that's in the packet with URG set, but the receiver
still has to receive the intervening data.

> Does anyone remember / recall / have an opinion on what happened to
> the use of the URG bit?

Well, having differing interpretations of the Urgent Data offset
field in various implementations didn't . Some discussions on
the TCP-IMPL list have also suggested that some of the assumptions
made about urgent-data handling in RFC 1122 weren't obvious to all
implementors. See for example the thread starting at

http://tcp-impl.grc.nasa.gov/list/archive/0764.html

which has some interesting discussion of URG handling.

One point which occurred to me reading these discussions: the
consensus seems to be that as soon as the sender tries to send urgent
data, the next outbound segment should have the URG flag set, even if
it doesn't contain any of the urgent data because more in-band data
is waiting to be sent than can fit in the segment / receiver's
window. However, presumably this can only be done if there's no more
than 64KB of data in front of the first OOB octet, because the Urgent
Pointer field is 16 bits.

Though on reflection maybe that's not possible, because TCP will
block the application's send operation, or in non-blocking mode
refuse to queue more outbound data, if the application tries to send
more than the receiver's window, which would prevent the sender from
queuing up lots of outbound normal data followed by OOB data. I
think.

--
Michael Wojcik michael.wojcik@microfocus.com

Don't forget your fighting spirit at each balls you pitch!
-- Tornado Boy Volunteer Staff International

12/03/2006, 18h27	#9
Michael Wojcik Messages: n/a Hébergeur:	Re: For performance, one socket or two with dedicated send/receive? In article <slrne128gf.l1l.dmfh@llanfaethlu.dmfh.cx>, DMFH <dmfh@n0spam.dmfh.cx.spamn0t> writes: > > Thinking back in this thread to using a single TCP socket instead of > multiple ones for performance, this thread reminds me of the URG > flag in TCP, and how (from my own experience) this was never quite used > or implemented in a useful way and how it might have ed out moving > control elements of a communication faster than content. (The following is assuming I'm remembering the semantics of URG correctly; I'm on a trip and don't have all my resources handy. No doubt I will be corrected where I'm wrong.) Urgent data doesn't get delivered to the receiving host any faster - it's just an indication that there's special (notionally out-of-band) data further ahead in the stream. "Further ahead" is allowed to be after the data that's in the packet with URG set, but the receiver still has to receive the intervening data. > Does anyone remember / recall / have an opinion on what happened to > the use of the URG bit? Well, having differing interpretations of the Urgent Data offset field in various implementations didn't . Some discussions on the TCP-IMPL list have also suggested that some of the assumptions made about urgent-data handling in RFC 1122 weren't obvious to all implementors. See for example the thread starting at http://tcp-impl.grc.nasa.gov/list/archive/0764.html which has some interesting discussion of URG handling. One point which occurred to me reading these discussions: the consensus seems to be that as soon as the sender tries to send urgent data, the next outbound segment should have the URG flag set, even if it doesn't contain any of the urgent data because more in-band data is waiting to be sent than can fit in the segment / receiver's window. However, presumably this can only be done if there's no more than 64KB of data in front of the first OOB octet, because the Urgent Pointer field is 16 bits. Though on reflection maybe that's not possible, because TCP will block the application's send operation, or in non-blocking mode refuse to queue more outbound data, if the application tries to send more than the receiver's window, which would prevent the sender from queuing up lots of outbound normal data followed by OOB data. I think. -- Michael Wojcik michael.wojcik@microfocus.com Don't forget your fighting spirit at each balls you pitch! -- Tornado Boy Volunteer Staff International