> On 6. jun. 2016, at 19.15, Joe Touch <[email protected]> wrote: > > > > On 6/6/2016 1:17 AM, Michael Welzl wrote: >>> On 27 Apr 2016, at 23:25, Joe Touch <[email protected]> wrote: >>> >>> >>> >>> On 4/27/2016 1:16 AM, Michael Welzl wrote: >>>> Thinking about Toerless' general point of using more modern APIs made >>>> me think of the bigger picture again. For example, one cool recent >>>> feature in TCP APIs is the SO_SNDLOWAT socket option, which allows >>>> better control of the sender buffer. Not including it in an API >>>> document "sucks" and it IS nice to include it in a description of an >>>> API. >>> This is an interesting example. It affects how a user-level process >>> interacts with the protocol implementation inside the OS but has NOTHING >>> to do with TCP. >>> >>> I'm not sure where I would put that. It clearly isn't part of the TCP >>> API. Nor, e.g., would be the "nice" level of the process that's feeding >>> data to TCP -- yet both could affect performance between two applications. >>> >>> It seems like there's a gap here you could drive a truck through that >>> needs to be addressed. I'm not sure where, though - i.e., whether this >>> is part of TAPS or not. >> Not part of TAPS I think, because it's not related to automatizing the use >> of protocols other than TCP or UDP. > > Please explain why you think that's true. > > AFAICT, it's fundamental to how any protocol interacts with the OS.
Yes it is, but it’s also orthogonal to the choice of protocol - as you said, it really has nothing to do with TCP. Using my typical example again: you can’t use an SCTP mechanism like e.g. unordered message delivery without knowing that the application wants it, or else you’ll break the semantics of the application data stream. It's is a mechanism of SCTP that simply cannot be used unless it’s chosen via an API. Can you say the same about this SO_SNDLOWAT stuff? As far as I’m concerned such send buffer management is an implementation detail - you could implement this very well or extremely badly for every protocol - but even an implementation that gives you almost no choice of what goes on in the buffer does not prohibit you from using a mechanism that a protocol provides. It’s a different matter, because the semantics stay unaltered: if you set the buffer very small with SO_SNDLOWAT, TCP will just fail on you. It’s not going to lose any packets, it stays reliable. If you could make it lose packets by changing SO_SNDLOWAT, that would be a different matter I think... Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
