[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