Michael Rogers wrote: > David Sowder (Zothar) wrote: > >> 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. >> > > So every service will have to deal with demultiplexing different users' > messages? > Yes. Only a service should care about the concept of a user. It's not exactly complicated. All it has to do is designate a field in the packet that specifies a user. My first use would probably be using a SimpleFieldSet, but that's up to the service. This is the correct approach in my thinking because chat/Alice and chat/Bob, while being represented by different instances, are still instances of the same service and thus should not have a different service ID (a.k.a. N2NM type). I suspect that if you look at how iChat handles chat over Bonjour, you'll find that the fact that it is an iChat instance is separate from the user's nickname represented by that instance and perhaps even the nickname's resource, if it's modeled after XMPP, which I believe it may be. >> Bonjour generally assumes that either everyone is on the same broadcast >> domain or that there is a centralized name lookup service available. >> > > Sorry, I should have been more specific. Multicast DNS and DNS service > discovery are two separate parts of Bonjour - I'm talking about DNS > service discovery, which doesn't require multicast or a centralised > lookup service. It's just a way to map service names to port numbers. > I'm not going to claim to be a Bonjour expert, so I'll simply comment that I understand service discovery to be separate from service name to port number mapping and if I remember correctly, in the case of Bonjour, they are closely tied together, even if separate. >> I >> believe we have to use the IANA approach because we don't want two >> separate "clouds" becoming connected to be a complex matter. >> > > I don't understand what you mean by clouds - I'm not talking about > multicast, just a way for a node to look up service ports on a peer, to > avoid the need to keep a centrally managed list of ports. > I'll give an example (using my "cloud" analogy):
Cloud 1: nodes A, B and C Cloud 2: nodes D, E and F Cloud 1 and Cloud 2 need to be using the same N2NM type ID number for a particular service if any of [A, B, C] connects with [D, E, F] if such a connection is to then allow all of [A, B, C, D, E, F] to potentially talk to each other because otherwise would involve some sort of "difference resolution protocol" to force either [A, B, C] or [D, E, F] to change their service name to N2NM type mapping to either the same N2NM type ID number of the other or a third N2NM type ID number used by [A, B, C, D, E, F]. The best way to use the same N2NM type ID number is for that particular service to always use the same N2NM type ID number everywhere it runs. The easiest way, then, to ensure that only that particular service is the only service using that N2NM type ID number is to have a central registry, we we currently have as implemented in the Fred source in trunk/freenet/src/freenet/node/Node.java. >> 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. >> > > True, it's not unmanagable - just unnecessary. :-) > How much more complex are things, however, if it is not used?
