[Taps] API design: dependencies or buffer control?

[Michael Welzl <[e-mail]>]

Hi,

Another thought related to the post-sockets draft:

Post-sockets lets an application programmer define dependencies. That’s good, because dependencies exist, but it comes at the cost of complexity.
My gut feeling tells me: if you have dependencies to take care of, it’s best to leave the data with the application and not hand it over to the transport at all until the last minute.

Controlling the buffer with something like TCP_NOTSENT_LOWAT would be a way for an application to only give the most recent, relevant data to the transport, and decide to throw away data on its own in case a preceding message was thrown away (which it might learn from transport).

I haven’t written code that uses TCP_NOTSENT_LOWAT myself, but I would guess that the trade-off in using this is: if you set this value low, you have more control over the buffer and can be more efficient in your decisions, but the disadvantage is that the transport permanently comes back to you and says “empty, empty, empty, ….” - which may be inconvenient / inefficient for the programmer.

If I’m right with all my musings here, then for an application that has block dependencies, the design should depend on what is easier to handle: defining priorities towards the transport layer on one side, or dealing with the transport calling us quickly all the time because its buffer is about to run empty, plus handling dependencies in the application on the other.

I don’t know - which one IS easier?

I’d love to see this discussed a little, and I’d also love to know if my interpretation of the trade-off in this email is even correct.

Cheers,
Michael