[elvin-discuss] Re: Elvin spec
David Arnold
david at mantara.com
Sun Apr 15 22:12:20 CDT 2007
-->"Ian" == Ian Lister <ilister at mantara.com> writes:
>>>> most important is the NACK code, i think. there's not much
>>>> alternative for a client library than passing back a
>>>> NOT_SUPPORTED to the application, but given it's allowable to
>>>> have routers without quench, etc, it's gotta be reported somehow.
>>> NO_ROUTER_SUPPORT, of course. If you got a NOT_SUPPORTED
>>> (implying the lack of support is local) you'd just give up and go
>>> home, but with NO_ROUTER_SUPPORT it's worth continuing to try
>>> other routers.
>> Not sure what the difference is? Either a request is recognised
>> but not supported or it's a protocol violation surely?
Ian> If the lack of support is local (e.g. your client library
Ian> implementation doesn't support quench) there's no request at all.
except that NO_ROUTER_SUPPORT and NOT_SUPPORTED are Mantara-specific,
libelvin error codes, not protocol NACK error codes.
in this case, i think the error should be treated similarly to a
subscription language syntax error: the state machines are still in
sync, it's just that a requested feature is unavailable from the current
router.
on that basis, i think error code 2007 would be appropriate? and,
assuming existing client libraries are correctly implemented, they
should cope nicely.
>> But it's an opportunity to point out that I'm thinking that
>> advertising the router using mDNS (Bonjour) might be a useful thing
>> to do. Any opinions?
Ian> Yes, Bonjour consists of IPv4LL (addressing), mDNS (naming) and
Ian> DNS-SD (discovery). ERDP is the existing Elvin Router Discovery
Ian> Protocol.
IPv4LL is about automatic address assignment in the absence of a DHCP
server. i think it's irrelevant to an Elvin router implemention.
mDNS is multicast DNS resolution. in itself, i think it's irrelevant
also (but see below).
DNS-SD is the interesting bit of Bonjour as far as service discovery
goes. IIRC (i haven't looked at it for a while), it uses a DNS name of
the form _service._protocol.local to identify the target service, and
mDNS resolve the query.
i think the service bit uses the IANA-assigned name for the protocol.
in the case of Elvin clients, that should be 'elvin_client' (although i
*think* underscore is illegal in DNS names, so not sure what's going
on there).
the protocol bit should be '_tcp' for TCP-based services.
this is all just my recollection.
Stuart Cheshire has a fairly helpful web site for all the specs, links,
etc.
sorry for the delay in posting this: i just found the unsent draft :-(
d
More information about the elvin-discuss
mailing list