Re: [Spud] discovery

[Michael Welzl <[e-mail]>]

> On 20 Mar 2015, at 03:00, Brian Trammell <[e-mail]> wrote:
> 
>> 
>> On 19 Mar 2015, at 19:21, Michael Welzl <[e-mail]> wrote:
>> 
>> 
>>> On 19. mar. 2015, at 17.18, Brian Trammell <[e-mail]> wrote:
>>> 
>>> hi Aaron,
>>> 
>>>> On 19 Mar 2015, at 11:48, Aaron Falk <[e-mail]> wrote:
>>>> 
>>>> The draft
>>> 
>>> ... where "the draft" is draft-hildebrand-spud-prototype ...
>>> 
>>>> doesn't say much about how one efficiently determines whether the other end is SPUD-capable so that an application can know whether it can use it.
>>> 
>>> No, it doesn't.
>>> 
>>>> Has anyone given thought to this?
>>> 
>>> Yes, I have...
>>> 
>>> I think for the most part that this question is (1) very important but (2) mostly orthogonal to that we're trying to answer in spud-prototype.
>>> 
>>> Initially, I would expect that discovery works the same way that it does for any other user of the transport layer: you either have a URL, or a name and a port, or some information from your application-layer protocol's discovery service, which includes "uses x-over-SPUD" in its semantics.
>>> 
>>> Dynamically discovering a SPUD endpoint might make sense if a server port / URL schema is assigned to a service over X or a service over x-over-SPUD. In this case, the magic number we've selected makes SPUD server probing by the client possible: a SPUD packet is neither valid UTF-8, UTF-16, UTF-32, ASN.1 BER or DER, DTLS, NTP, DNS, DHCP, TFTP, or Bittorrent. This is not an exhaustive list, but we haven't found a protocol over UDP that is likely to consider d8 00 00 d8 as the first four bytes anything other than an error.
>> 
>> - but that won't tell you if SPUD actually does work across the path...
> 
> True. But discovery (is there an endpoint there?) is a separate question from path transparency (once you've found the endpoint, can you actually talk to it?)

Not entirely I think - see below:


> This would be an argument for specifying a dynamic discovery method, though -- not for determining whether you should use SPUD, but whether you can.

So I think, as much as some folks seem to hate it, there really isn't a way around happy-eyeballing...
the reason I say it's not entirely separate ifrom discovery s that happy eyeballs can check availability both on the path and the other end in one go. However, having a separate method that really only deals with the other end can limit how much happy eyeballing one needs to do (i.e.: no point even trying SPUD if the other side doesn't use it).

Cheers,
Michael