Re: [Taps] New Version Notification for draft-trammell-post-sockets-00.txt

[Brian Trammell <[e-mail]>]

hi Michael,

(snipping some history...)

>> (2) Alternately, a Post implementation more tightly integrated with a TAPS one could raise errors on attempts to use contracts not supported by the underlying transport. This requires more application logic support, though, and negates one of the advantages we see of this approach: write once, use any transport.
> 
> The approach we ended up taking in NEAT (to be presented) is to always choose between "required" or "desired".
> "Required" means the API fails and gets back to you; "desired" means you get a fall-back as you describe here. This yields the flexibility that TAPS wants to achieve, yet allows applications to be in control of the things they really must control.

That's a good distinction to make. This, of course, doesn't solve the problem of needing a framing to make this work, as noted below.

>>> I mean, draft-mcquistin-taps-low-latency-services-00.txt even explicitly says "The next phase, enabled both by the use of transport services and their separation from transport protocols, is to define novel transport services based on the needs of applications."
>>> I'd say this is clearly *not* what the charter says. When TAPS started, lots of folks wanted this, but TAPS would have never seen the light of day if we had put that in the charter. Now maybe it's time to be more forward-looking?
>> 
>> Post doesn't say this *explicitly*, but I think you've noticed that it's kind of assumed. Yes, I do think it's time to be forward-looking. Where that looking forward happens is a different question: it could happen in TAPS, or in its own WG or RG. In any case, it definitely needs to happen hand in hand with TAPS, as it's an effort that can provide more diversity in ways to implement services and features.
> 
> So here's a question. To implement e.g. Post with TCP, one could also provide a layer on top of TCP that offers the suggested API and at least takes care of message delineation (and then that layer could use other protocols instead of TCP too). This would need to be there on both ends of a connection.
> I mean, AFAIK, as Minion developed, it was at some point suggested to not insert a delimiter in TCP as part of TCP's functionality, but to simply use delimiters coming from app-layer protocols. I.e., when that protocol has a delimiter, why use another one?
> 
> If that's what we need, then all of a sudden, we're not discussing a forward-looking wish-list anymore, but a way to implement a TAPS system. I'd think that would be a better direction than just creating a wish list for new protocols... but both could be done, I guess.

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 :) )

>> 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. 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 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?)

Cheers,

Brian