Re: [jdev] discovery services
Hi Peter, hi Matt, ... Matt Tucker schrieb am 2005-03-22 17:37:25: You could use zero-configuration networking for the discovery: To add to this thread, we already support multicast DNS (called Rendezvous by Apple) in Jive Messenger (Open Source server at http://www.jivesoftware.org). May I add a third protocol proposal? Mine is SLP (RFC 2608 et all) which I started to experiment with in jabberd14 (won't be commited before after 1.4.4). Maybe we really should talk about service discovery protocols before everybody starts using his own protocol. Tot kijk Matthias ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On 23 Mar 2005, at 0:31, Justin Karneges wrote: On Tuesday 22 March 2005 05:31 pm, Julian Missig wrote: On 22 Mar 2005, at 20:00, Justin Karneges wrote: Ignoring how iChat may or may not do it, I figure the most straightforward answer would be to have the clients perform the xmpp-core s2s protocol with each other. JIDs become [EMAIL PROTECTED] Honestly, I prefer iChat's approach. Clients already have client libraries that speak the c2s protocol. You strip out some of the login/auth stuff and just use c2s to one another. That requires a lot less new implementation and allows for a lot more code re-use... at least the way Jabberoo was designed and how I imagine most libraries are designed. Since it's local I don't really see a need for Dialback and its multiple socket connections and all sorts of other server pains that client developers haven't had to be exposed to yet. You make a good point, dialback is probably not needed. Perhaps the login handshake can be done using SASL. However, everything else in an ad-hoc setup is unavoidably more like s2s than c2s. Here is what implementations need in addition to regular c2s: 1) ability to handle incoming TCP connections That's a feature of the actual implementation, not the protocol used once the TCP connection is established. This is easy to add to existing client libraries. 2) ability to perform the XMPP stream handshake process in reverse Simple enough to add in place of the regular auth support. 3) stanzas need to indicate both the 'to' and the 'from' (since either workstation might have multiple users. yes, I think we should be forward thinking here). Ok, this is pretty silly and makes the problem thousands of times harder. DNS-SD lends itself to be used as presence broadcasting, but then you /can't/ use it as presence broadcasting if there are multiple users connected without making /those/ packets insanely complicated too. I don't think that's a problem we should be focusing on at all, because I don't see how it's going to make anything simpler /or/ better. I think that for now we should focus on things which DNS-SD has proven useful for. Multiple users advertising the same service on one computer is not one of them, and until the DNS-SD people have a good solution for that (if they care about it at all), I don't think we should. I really think it shouldn't be that hard to take a random client library, hook it up to a DNS-SD and Multicast DNS library, change a couple of things, and have a working client. The hardest part should be gutting the presence implementation for use with DNS-SD. Julian ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On Tue, Mar 22, 2005 at 08:31:54PM -0500, Julian Missig wrote: Honestly, I prefer iChat's approach. Clients already have client libraries that speak the c2s protocol. You strip out some of the login/auth stuff and just use c2s to one another. That requires a lot less new implementation and allows for a lot more code re-use... at least the way Jabberoo was designed and how I imagine most libraries are designed. Since it's local I don't really see a need for Dialback and its multiple socket connections and all sorts of other server pains that client developers haven't had to be exposed to yet. +1. Keep it simple. /psa ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On Wednesday 23 March 2005 06:27 am, Julian Missig wrote: On 23 Mar 2005, at 0:31, Justin Karneges wrote: 3) stanzas need to indicate both the 'to' and the 'from' (since either workstation might have multiple users. yes, I think we should be forward thinking here). Ok, this is pretty silly and makes the problem thousands of times harder. DNS-SD lends itself to be used as presence broadcasting, but then you /can't/ use it as presence broadcasting if there are multiple users connected without making /those/ packets insanely complicated too. I don't think that's a problem we should be focusing on at all, because I don't see how it's going to make anything simpler /or/ better. I don't follow. Existing client code is going to expect 'from' attributes on incoming stanzas. This means that either 1) the clients have to be hacked to not care about 'from' attributes on incoming stanzas or 2) clients need to put 'from' attributes on the stanzas they send out. #2 is not a thousand times harder than #1. Supporting multiple users on a single machine might be a thousand times harder, but you're not forced to do that. A single-user ad-hoc client should have no trouble interoperating. I think that for now we should focus on things which DNS-SD has proven useful for. Multiple users advertising the same service on one computer is not one of them, and until the DNS-SD people have a good solution for that (if they care about it at all), I don't think we should. Unless I've misunderstood how zeroconf works, I thought that you'd announce a single service regardless of whether or not the service was single-user or multiple-user. Yes, this probably means that for multiple-users you'd need an ad-hoc Jabber client daemon. No, I'm not saying anyone has to implement it that way. -Justin ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On 23 Mar 2005, at 16:00, Justin Karneges wrote: On Wednesday 23 March 2005 06:27 am, Julian Missig wrote: On 23 Mar 2005, at 0:31, Justin Karneges wrote: 3) stanzas need to indicate both the 'to' and the 'from' (since either workstation might have multiple users. yes, I think we should be forward thinking here). Ok, this is pretty silly and makes the problem thousands of times harder. DNS-SD lends itself to be used as presence broadcasting, but then you /can't/ use it as presence broadcasting if there are multiple users connected without making /those/ packets insanely complicated too. I don't think that's a problem we should be focusing on at all, because I don't see how it's going to make anything simpler /or/ better. I don't follow. Existing client code is going to expect 'from' attributes on incoming stanzas. This means that either 1) the clients have to be hacked to not care about 'from' attributes on incoming stanzas or 2) clients need to put 'from' attributes on the stanzas they send out. #2 is not a thousand times harder than #1. Supporting multiple users on a single machine might be a thousand times harder, but you're not forced to do that. A single-user ad-hoc client should have no trouble interoperating. I think that for now we should focus on things which DNS-SD has proven useful for. Multiple users advertising the same service on one computer is not one of them, and until the DNS-SD people have a good solution for that (if they care about it at all), I don't think we should. Unless I've misunderstood how zeroconf works, I thought that you'd announce a single service regardless of whether or not the service was single- user or multiple-user. Yes, this probably means that for multiple-users you'd need an ad-hoc Jabber client daemon. No, I'm not saying anyone has to implement it that way. Yes, except that the iChat way of doing this makes a *lot* of sense. I don't know how you're expecting to to distribute presence using DNS- SD, but with iChat, the service it's advertising *is* the presence. So this is sort of by definition single-user. Julian smime.p7s Description: S/MIME cryptographic signature ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On Wednesday 23 March 2005 01:13 pm, Julian Missig wrote: Yes, except that the iChat way of doing this makes a *lot* of sense. I don't know how you're expecting to to distribute presence using DNS- SD, but with iChat, the service it's advertising *is* the presence. So this is sort of by definition single-user. Ahhh, I see now. So does it actually advertise a Jabber presence stanza over DNS-SD? Or is it some alternative format? And how is this process by definition single-user? It seems like if you can include one presence chunk in the advertisement, you could include two (at the risk of violating iChat's existing protocol), but again I know very little about DNS-SD. I still feel it would be more Jabber-like to obtain the presence over the Jabber connection, but I can see how doing it over DNS-SD might be more optimized for the situation. -Justin ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On 23 Mar 2005, at 16:47, Justin Karneges wrote: On Wednesday 23 March 2005 01:13 pm, Julian Missig wrote: Yes, except that the iChat way of doing this makes a *lot* of sense. I don't know how you're expecting to to distribute presence using DNS- SD, but with iChat, the service it's advertising *is* the presence. So this is sort of by definition single-user. Ahhh, I see now. So does it actually advertise a Jabber presence stanza over DNS-SD? Or is it some alternative format? And how is this process by definition single-user? It seems like if you can include one presence chunk in the advertisement, you could include two (at the risk of violating iChat's existing protocol), but again I know very little about DNS-SD. I still feel it would be more Jabber-like to obtain the presence over the Jabber connection, but I can see how doing it over DNS-SD might be more optimized for the situation. What Jabber connection are you talking about? I don't mean to be presumptuous or rude, but I really don't think you've thought through DNS-SD and how peer-to-peer Jabber would work with it nearly enough... There's a local subnet. It has 50 users on it. How are you expecting that those 50 users will get one another's presence? DNS-SD means that we can treat the service as a presence packet (because really, it is advertising the availability of a service) and advertise our presence as a DNS-SD service. There's no need to open up 50 TCP connections and send presence/ packets to all 50. It's all handled by Multicast DNS for us. There's no Jabber connection taking place until one user wants to send a message to another--then we're opening a TCP socket and sending a message. I don't see why you need the 'from' attribute because you already know who the TCP socket connection is from and you already have their information from the DNS-SD service packet. Julian ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On Wednesday 23 March 2005 02:07 pm, Julian Missig wrote: I don't mean to be presumptuous or rude, but I really don't think you've thought through DNS-SD and how peer-to-peer Jabber would work with it nearly enough... Probably not. I was just trying to see how much of our own protocol we could re-use. I had not yet considered ooberizing presence. There's a local subnet. It has 50 users on it. How are you expecting that those 50 users will get one another's presence? DNS-SD means that we can treat the service as a presence packet (because really, it is advertising the availability of a service) and advertise our presence as a DNS-SD service. There's no need to open up 50 TCP connections and send presence/ packets to all 50. It's all handled by Multicast DNS for us. There's no Jabber connection taking place until one user wants to send a message to another--then we're opening a TCP socket and sending a message. Does this mean that presence is never delivered over a Jabber connection, even if there is an existing connection due to some message exchanging? What about directed presence? -Justin ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On 23 Mar 2005, at 18:33, Justin Karneges wrote: On Wednesday 23 March 2005 02:07 pm, Julian Missig wrote: I don't mean to be presumptuous or rude, but I really don't think you've thought through DNS-SD and how peer-to-peer Jabber would work with it nearly enough... Probably not. I was just trying to see how much of our own protocol we could re-use. I had not yet considered ooberizing presence. There's a local subnet. It has 50 users on it. How are you expecting that those 50 users will get one another's presence? DNS-SD means that we can treat the service as a presence packet (because really, it is advertising the availability of a service) and advertise our presence as a DNS-SD service. There's no need to open up 50 TCP connections and send presence/ packets to all 50. It's all handled by Multicast DNS for us. There's no Jabber connection taking place until one user wants to send a message to another--then we're opening a TCP socket and sending a message. Does this mean that presence is never delivered over a Jabber connection, even if there is an existing connection due to some message exchanging? What about directed presence? Yes. If you really want directed presence, it could in theory be sent over the TCP connection. iChat doesn't support directed presence at all. Julian smime.p7s Description: S/MIME cryptographic signature ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
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 waaay off here??? If so, would someone write down a step-by-step scenario of how this would work? cheers! Anthony On Wed, 23 Mar 2005 15:33:39 -0800, Justin Karneges [EMAIL PROTECTED] wrote: On Wednesday 23 March 2005 02:07 pm, Julian Missig wrote: I don't mean to be presumptuous or rude, but I really don't think you've thought through DNS-SD and how peer-to-peer Jabber would work with it nearly enough... Probably not. I was just trying to see how much of our own protocol we could re-use. I had not yet considered ooberizing presence. There's a local subnet. It has 50 users on it. How are you expecting that those 50 users will get one another's presence? DNS-SD means that we can treat the service as a presence packet (because really, it is advertising the availability of a service) and advertise our presence as a DNS-SD service. There's no need to open up 50 TCP connections and send presence/ packets to all 50. It's all handled by Multicast DNS for us. There's no Jabber connection taking place until one user wants to send a message to another--then we're opening a TCP socket and sending a message. Does this mean that presence is never delivered over a Jabber connection, even if there is an existing connection due to some message exchanging? What about directed presence? -Justin ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
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 waaay 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 smime.p7s Description: S/MIME cryptographic signature ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
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 [EMAIL PROTECTED] 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 waaay 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@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
There is no such thing as a JabberID in this system. JabberIDs are [EMAIL PROTECTED], 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 [EMAIL PROTECTED] 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 waaay 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@jabber.org http://mail.jabber.org/mailman/listinfo/jdev smime.p7s Description: S/MIME cryptographic signature ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On Thu, Mar 17, 2005 at 05:28:16PM -0800, Leonardo Galicia Jimenez wrote: Hi everybody, my name is Leonardo and i am trying to implement a system using jabber. In this system i program jabber client using java, but these jabber clients work transparently to the user, each jabber client is called agent and represents devices, services, objets or users, each one with its own features and attributes. These agents need to be discover by others agents, for instance, one agent (jabber client) represents a user and need to discover automatically a other agent that represent a printer in all the jabber network. I wonder if jabber technology has a discovery way similar to Slp, Jxta, Jini, etc, besides JEP-0030 i didn't find it, or other way to find others jabber servers. I have interest in use jabber for the presence protocol, simple and the easy way to extend it. If anybody has information about it, i really will appreciate it. You could use zero-configuration networking for the discovery: http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac206/about_cisco_ipj_archive_article09186a0080132b85.html TinyURL: http://tinyurl.com/4bz7v Then use JEP-0030 for detailed service information. Or you could write a server-side component that has more information about entities on your network (something like a Jabber User Directory but for network services). Will your network entities have stable addresses or JabberIDs, or do you require dynamic discovery? /psa ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
RE: [jdev] discovery services
You could use zero-configuration networking for the discovery: http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac206/about _cisco_ipj_archive_article09186a0080132b85.html To add to this thread, we already support multicast DNS (called Rendezvous by Apple) in Jive Messenger (Open Source server at http://www.jivesoftware.org). So, you would use mdns to automatically discover the central XMPP server and then normal disco, presence, etc, to find other clients that support the services you're looking for as Peter suggests. Jive Messenger lists itself using the _xmpp-client._tcp.local. service name, which mirrors the XMPP DNS SRV entry. Regards, Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Saint-Andre Sent: Tuesday, March 22, 2005 12:59 PM To: Jabber software development list Subject: Re: [jdev] discovery services On Thu, Mar 17, 2005 at 05:28:16PM -0800, Leonardo Galicia Jimenez wrote: Hi everybody, my name is Leonardo and i am trying to implement a system using jabber. In this system i program jabber client using java, but these jabber clients work transparently to the user, each jabber client is called agent and represents devices, services, objets or users, each one with its own features and attributes. These agents need to be discover by others agents, for instance, one agent (jabber client) represents a user and need to discover automatically a other agent that represent a printer in all the jabber network. I wonder if jabber technology has a discovery way similar to Slp, Jxta, Jini, etc, besides JEP-0030 i didn't find it, or other way to find others jabber servers. I have interest in use jabber for the presence protocol, simple and the easy way to extend it. If anybody has information about it, i really will appreciate it. TinyURL: http://tinyurl.com/4bz7v Then use JEP-0030 for detailed service information. Or you could write a server-side component that has more information about entities on your network (something like a Jabber User Directory but for network services). Will your network entities have stable addresses or JabberIDs, or do you require dynamic discovery? /psa ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On Tue, Mar 22, 2005 at 05:37:25PM -0600, Matt Tucker wrote: You could use zero-configuration networking for the discovery: http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac206/about _cisco_ipj_archive_article09186a0080132b85.html To add to this thread, we already support multicast DNS (called Rendezvous by Apple) in Jive Messenger (Open Source server at http://www.jivesoftware.org). So, you would use mdns to automatically discover the central XMPP server and then normal disco, presence, etc, to find other clients that support the services you're looking for as Peter suggests. Jive Messenger lists itself using the _xmpp-client._tcp.local. service name, which mirrors the XMPP DNS SRV entry. Cool. Perhaps it would make sense to write up a best practices document for use by developers who want to build multicast DNS / zero-configuration networking into their XMPP-based applications? Or perhaps that belongs in the long-rumored XMPP implementation guide. :-) /psa ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On 22 Mar 2005, at 18:37, Matt Tucker wrote: You could use zero-configuration networking for the discovery: http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac206/about _cisco_ipj_archive_article09186a0080132b85.html To add to this thread, we already support multicast DNS (called Rendezvous by Apple) in Jive Messenger (Open Source server at http://www.jivesoftware.org). So, you would use mdns to automatically discover the central XMPP server and then normal disco, presence, etc, to find other clients that support the services you're looking for as Peter suggests. Jive Messenger lists itself using the _xmpp-client._tcp.local. service name, which mirrors the XMPP DNS SRV entry. Why _xmpp-client if you're advertising an XMPP Server? Julian ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On 22 Mar 2005, at 19:14, Julian Missig wrote: On 22 Mar 2005, at 18:37, Matt Tucker wrote: You could use zero-configuration networking for the discovery: http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac206/about _cisco_ipj_archive_article09186a0080132b85.html To add to this thread, we already support multicast DNS (called Rendezvous by Apple) in Jive Messenger (Open Source server at http://www.jivesoftware.org). So, you would use mdns to automatically discover the central XMPP server and then normal disco, presence, etc, to find other clients that support the services you're looking for as Peter suggests. Jive Messenger lists itself using the _xmpp-client._tcp.local. service name, which mirrors the XMPP DNS SRV entry. Why _xmpp-client if you're advertising an XMPP Server? Oh nevermind. I see that stpeter registered xmpp-client and xmpp- server, intending that xmpp-client be the service that XMPP Clients connect *to* while xmpp-server be the server-to-server connection. Kind of odd, but it's what's registered... so nevermind. Julian ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On Tue, Mar 22, 2005 at 07:16:50PM -0500, Julian Missig wrote: Why _xmpp-client if you're advertising an XMPP Server? Oh nevermind. I see that stpeter registered xmpp-client and xmpp- server, intending that xmpp-client be the service that XMPP Clients connect *to* while xmpp-server be the server-to-server connection. Kind of odd, but it's what's registered... so nevermind. Hmm, I see where you're going -- we might want to have a service that would enable clients to connect to each other (a la iChat's Rendezvous mode or whatever they're going to call it after the Tibco dispute)... Peter ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On 22 Mar 2005, at 19:25, Peter Saint-Andre wrote: On Tue, Mar 22, 2005 at 07:16:50PM -0500, Julian Missig wrote: Why _xmpp-client if you're advertising an XMPP Server? Oh nevermind. I see that stpeter registered xmpp-client and xmpp- server, intending that xmpp-client be the service that XMPP Clients connect *to* while xmpp-server be the server-to-server connection. Kind of odd, but it's what's registered... so nevermind. Hmm, I see where you're going -- we might want to have a service that would enable clients to connect to each other (a la iChat's Rendezvous mode or whatever they're going to call it after the Tibco dispute)... Well, even without that, the service name is supposed to be the service you're advertising. The XMPP server is advertising an XMPP connection to which a client can connect, which from a server's point of view might be xmpp-client, yes, but from a client's point of view, it seems an odd thing to be looking for a client service when you want to connect to an XMPP Server. Pedantry, I admit, but it had me confused for a few minutes. For an official form of something like iChat Rendezvous, we'd need to define what exactly an XMPP client-client protocol should look like, which pieces of XMPP are disallowed, and when TCP connections should actually take place. All things which I was interested in doing back when it looked like something I'd be adding to Gabber one day, but which unfortunately I don't think I'll be implementing in anything anytime soon... Julian ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On Tuesday 22 March 2005 04:40 pm, Julian Missig wrote: For an official form of something like iChat Rendezvous, we'd need to define what exactly an XMPP client-client protocol should look like, which pieces of XMPP are disallowed, and when TCP connections should actually take place. All things which I was interested in doing back when it looked like something I'd be adding to Gabber one day, but which unfortunately I don't think I'll be implementing in anything anytime soon... Ignoring how iChat may or may not do it, I figure the most straightforward answer would be to have the clients perform the xmpp-core s2s protocol with each other. JIDs become [EMAIL PROTECTED] What we just need then is some document explaining the zeroconf process of locating local Jabber servers, both for xmpp-client and xmpp-server, and a way to query an xmpp-server for its users. The xmpp-server type could be either a real server (in the Jive sense), or an ad-hoc rendezvous-style workstation hosting a single user. To outsiders, it really makes no difference. Finally, although not strictly necessary, a nice iq protocol for normal Jabber clients to access the above features via an intermediate Jabber server would make it easier for existing clients to become ad-hoc aware. -Justin ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On 22 Mar 2005, at 20:00, Justin Karneges wrote: On Tuesday 22 March 2005 04:40 pm, Julian Missig wrote: For an official form of something like iChat Rendezvous, we'd need to define what exactly an XMPP client-client protocol should look like, which pieces of XMPP are disallowed, and when TCP connections should actually take place. All things which I was interested in doing back when it looked like something I'd be adding to Gabber one day, but which unfortunately I don't think I'll be implementing in anything anytime soon... Ignoring how iChat may or may not do it, I figure the most straightforward answer would be to have the clients perform the xmpp-core s2s protocol with each other. JIDs become [EMAIL PROTECTED] What we just need then is some document explaining the zeroconf process of locating local Jabber servers, both for xmpp-client and xmpp- server, and a way to query an xmpp-server for its users. The xmpp-server type could be either a real server (in the Jive sense), or an ad-hoc rendezvous-style workstation hosting a single user. To outsiders, it really makes no difference. Finally, although not strictly necessary, a nice iq protocol for normal Jabber clients to access the above features via an intermediate Jabber server would make it easier for existing clients to become ad-hoc aware. Honestly, I prefer iChat's approach. Clients already have client libraries that speak the c2s protocol. You strip out some of the login/auth stuff and just use c2s to one another. That requires a lot less new implementation and allows for a lot more code re-use... at least the way Jabberoo was designed and how I imagine most libraries are designed. Since it's local I don't really see a need for Dialback and its multiple socket connections and all sorts of other server pains that client developers haven't had to be exposed to yet. Julian ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
Re: [jdev] discovery services
On Tuesday 22 March 2005 05:31 pm, Julian Missig wrote: On 22 Mar 2005, at 20:00, Justin Karneges wrote: Ignoring how iChat may or may not do it, I figure the most straightforward answer would be to have the clients perform the xmpp-core s2s protocol with each other. JIDs become [EMAIL PROTECTED] Honestly, I prefer iChat's approach. Clients already have client libraries that speak the c2s protocol. You strip out some of the login/auth stuff and just use c2s to one another. That requires a lot less new implementation and allows for a lot more code re-use... at least the way Jabberoo was designed and how I imagine most libraries are designed. Since it's local I don't really see a need for Dialback and its multiple socket connections and all sorts of other server pains that client developers haven't had to be exposed to yet. You make a good point, dialback is probably not needed. Perhaps the login handshake can be done using SASL. However, everything else in an ad-hoc setup is unavoidably more like s2s than c2s. Here is what implementations need in addition to regular c2s: 1) ability to handle incoming TCP connections 2) ability to perform the XMPP stream handshake process in reverse 3) stanzas need to indicate both the 'to' and the 'from' (since either workstation might have multiple users. yes, I think we should be forward thinking here). Hmm, have I described ad-hoc or s2s? You can decide. :) -Justin ___ jdev mailing list jdev@jabber.org http://mail.jabber.org/mailman/listinfo/jdev
