Hi, Snipping too...
> So I'm not sure I understand what you're suggesting here... are you saying > that there'd be some application-layer callback to determine where the > framing is on the receive side? Yeah, that might work. (If that's not what > you're saying... well, it might work anyway :) ) Yes that’s what I meant >>> Again, two approaches I can see to make this happen, neither of which is >>> very good IMO: >>> >>> (1) Define a framing layer (or choose an existing one; for maximum layer >>> confusion, how about websockets? ;) ) to run over vanilla TCP; in this >>> case, Post is less of an API than a flexible transport layer, since it >>> can't be used to connect to endpoints not running Post. >>> >>> (2) When running on vanilla TCP, only open_stream() works on an >>> association. Same drawbacks as in (2) above. >>> >>> Maybe try 1 with a fallback to 2, but then you'd need a negotiation >>> protocol running at both ends, rather than a sensing layer that can work at >>> each endpoint independently as in TAPS. >> >> Sorry for inventing the same as you in my answer above :-) it seems we >> completely agree here. I also agree that both (1) and (2) would be possible >> solutions. >> Interesting idea about the fallback - indeed, wouldn't trying (1) with a >> fallback to (2) be ideal?! > > Yes, except that there the application has to know about the fallback, and > has to work with streams, which changes its logic. Yes, but no way around that unless you know what’s going on on the receiver side. > And it'd be nice if we could avoid that. But if there were a way to piggyback > on application-layer framing, that might make this less awkward. I would have thought the opposite? I don’t know what an API that uses app-layer framing looks like (I guess Jana worked on that while at Apple?), but I suspect it’s more awkward than just having delimiters available from below? Somehow the transport, or shim layer above it, on both sides, needs to be able to identify the delimiter, and so the format must be known to it. This means that the application would have to tell that layer the format of its app-layer delimiter - rather than just having a post-like interface that uses messages or objects, and perhaps getting a failure / fallback, which - I think - is annoying but inevitable. So, considering that delimiters are the key missing piece here, maybe TAPS should define how such a shim over TCP should work, with delimiters and signaling to be able to fall back if the other side doesn’t have it? > I think we're on to something. In any case, it definitely answers the first > question we had (do we want to talk about this further in a TAPS context?) Yes… I agree, I think we’re on to something here. Thanks again, actually to all authors of both these drafts, for helping make TAPS more interesting! Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
