> >> IMHO, the API will do well to let the client advise it regarding what >> type of interface it wants, and go with it.
Sure! But my point was that a byte stream can always be constructed over a packet stream for those who want it, at the potential loss of some efficiency. Vice versa doesn't make much sense to me - messages over a byte stream that then is split into packets that are sent over the networks is just silly. Yes certainly many apps do that over TCP (because TCP gives them many other good things and mostly works), but that sort of mismatch is what TAPS could help solve. Hence, what I'd suggest is to not even consider "byte stream" in TAPS discussions - e.g. as a "service" or anything like that. Certainly, yes, a TAPS-based interface can always provide one. As for Structured Streams, it's a nice paper but I never saw how this is much different from SCTP... anyway, bringing that into the discussion blends the *byte stream* that we're talking about here with *multi-streaming* (which is what Structured Streams is about), which are really two separate things despite the name similarity. Multi-streaming can be (and is in fact best) done with messages, not a byte stream. As always, one can stack a byte stream on top with a possible efficiency loss. Cheers, Michael
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
