Michael Rogers wrote:
> David Sowder (Zothar) wrote:
>   
>> The name to number lookup service would have to be globally unique, at 
>> least between all of the nodes that peer with each other directly and 
>> use that client.  The IANA style is required here for that reason 
>> (unless I'm forgetting something about Bonjour).
>>     
>
> I'm not sure what you mean by globally unique. Let's say nodes X and Y
> are peers. A client on node X wants to contact the corresponding server
> on node Y. The IANA approach is for each service to use a well-known
> port. The Bonjour approach is for each node to run a lookup service on a
> well-known port, which can be used to look up the port of any other
> service. So the client on node X contacts node Y's lookup service, gives
> it the service name, and gets the port number.
>
> This makes it easier to deploy new services, and you can also handle
> multiple users running instances of the same service on the same
> machine, for example by using service names like chat/Alice and chat/Bob.
>   
chat/Alice and chat/Bob are not separate services.  Separate users would 
be handled at a higher level.  All chat clients of a particular type 
would use the same N2NM id number.

Bonjour generally assumes that either everyone is on the same broadcast 
domain or that there is a centralized name lookup service available.  I 
believe we have to use the IANA approach because we don't want two 
separate "clouds" becoming connected to be a complex matter.

As for easily deploying new services, new services would simply use an 
ID out of the experimental range until a dev with commit access could be 
contacted, a process which is an IRC channel and a few minutes or hours 
away generally, unlike the real IANA, which I believe to be an email 
message or two and maybe a few days or weeks away.

Reply via email to