This discussion is as old as TCP. One can build a message interface on a stream interface (RFCs 1006 and 2126) and a stream interface on a packet interface. When I want to send a large message, such as a file, the difference between the two is difficult to discern: either way one slices that cookie, one has a lot of transport PDUs being sent; the only real difference is at the receiving end, which might want to receive the stream as it arrives or the message when it has completely arrived.
IMHO, the API will do well to let the client advise it regarding what type of interface it wants, and go with it. On Jun 27, 2014, at 7:45 AM, Michael Welzl <[email protected]> wrote: > Hi, > > I changed the subject because this is not about the chartering discussion > anymore - it's beginning our work :-) > > > Toby, in his last email, raised the following question: > > On 27. juni 2014, at 16:21, Toby Moncaster <[email protected]> > wrote: > > [snip] > > >>>>>> - message atomicity >>>> >>>> What's that? That multiple messages are not combined into one packet? This >>>> plays a role for an application only when there is significant loss (I >>>> think). Wouldn't it be nice to have a system that provides atomicity only >>>> when needed and otherwise saves header overhead? I would vote against >>>> exposing that. Either way, I vote it off the list that goes in the >>>> charter, it's not an obvious service to me. >> >> To some extent I agree here. But is there any way we can correctly express >> the differences between stream and packet oriented transports? > > Can we try to make a simple decision here, as a group, to never even really > consider streams at all? > > It seems to me to be straightforward to provide a stream-based transport over > a message-based transport, so this is something that can simply always be > done. Thus, can we just write a disclaimer in one of our documents, > recommending that any TAPS-supporting systems can provide stream-based > transport on top of the message based transport too, but that its users must > be aware of limitations that arise from streams (such as HOL blocking delay, > no ALF, ..)? > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
