[jdev] discovery services
julian at jabber.org
Wed Mar 23 18:49:34 CST 2005
There is no such thing as a JabberID in this system. JabberIDs are
user at server, and depend upon having a server.
Identification in this system is dependent upon Multicast DNS and DNS-
SD, which is how you get the IPs to connect to, the machine names,
etc. All of that stuff is thus defined by how mDNS and DNS-SD work.
It's important to note that this system only exists as a network as
large as your local mDNS network... which is usually just a single
On 23 Mar 2005, at 19:45, Anthony Ortiz wrote:
> "I SEE!!!" said the blind man to the deaf man...
> That seems like an interesting idea, though I think the current jabber
> protocol doesn't allow for this (am I right?) UDP/Multicast chatting
> is old-school, but I had never thought of using xmpp over it. I'm
> curious though... under this system, Jabber ID's will no longer be
> unique since 2 or more people can connect using the same JID. How
> would this system prevent this from happening? Since there's no
> authentication mechanism, how would it prevent someone from logging in
> as someone else and pretending to be that person? Is this defined
> somewhere? I would love to check it out in more detail...
> On Wed, 23 Mar 2005 19:20:46 -0500, Julian Missig
> <julian at jabber.org> wrote:
>> On 23 Mar 2005, at 19:13, Anthony Ortiz wrote:
>>> Okay, I'm confused... am I to understand that the jabber protocol
>>> be implemented over UDP/TCP-multicast?? I can see now how it would
>>> sort of work... is there a JEP on this??? I would assume that it
>>> follow something along these lines :
>>> 1) client broadcasts its presence (<stream:stream
>>> to="SomeJabberServer"> stanza I assume)
>>> 2) jabber server ("SomeJabberServer") opens TCP/IP connection with
>>> 3) ... authentication stuff happens here over dedicated TCP/IP
>>> connection (don't need this stuff broadcasted) ...
>>> 4) TCP/IP connection terminated
>>>> From this point on, I assume that everything else is handled via
>>> or multicast, except for messaging and file xfers and anything else
>>> that is direct? Or am I just waaaaaaaaaaaaaaay off here??? If so,
>>> would someone write down a step-by-step scenario of how this would
>> iChat basically already does Jabber without a Jabber server. It is
>> not /technically/ Jabber because we define Jabber as having servers,
>> but it is possible. We're not talking about involving a Jabber Server
>> at all.
>> 1) Client broadcasts presence using Multicast DNS and DNS-Service
>> 2) All clients on local network receive these presence packets as
>> defined by those protocols
>> 3) when user wants to send a message to another user, open a TCP
>> 4) send messages over that direct TCP client-to-client connection
>> 5) TCP client-to-client connection terminated
>> Multicast DNS and DNS-SD are typically UDP, not TCP.
>> This is *NOT* currently a defined protocol in any way, shape, or
>> form. iChat does something along these lines. We're currently talking
>> about IF we were to define such a thing how it would be done.
>> Justin and I were arguing about what would happen at my step 4,
>> except Justin's idea for how these steps happened seems to have been
>> quite different from mine, which is why we both wasted so much time
>> on it. :)
> jdev mailing list
> jdev at jabber.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2102 bytes
Desc: not available
More information about the JDev