[jdev] discovery services

[Julian Missig]

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  
subnet.

Julian

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...
>
> cheers!
>
> Anthony
>
>
> 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  
>>> can
>>> 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  
>>> would
>>> 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
>>> client
>>> 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  
>>>> UDP
>>> 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
>>> work?
>>>
>>
>> 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
>> Discovery
>> 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
>> connection
>> 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. :)
>>
>> Julian
>>
>>
>>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mail.jabber.org/mailman/listinfo/jdev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2102 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20050323/49231387/attachment-0002.bin>