[JDEV] Peer to peer Jabber streams (was: Cool ICQ style messages)
Stephen D. Williams
sdw at lig.net
Fri Jan 26 10:26:43 CST 2001
Please include me in these discussions. I have been thinking about this
also.
The key consideration is that peer-to-peer is great when you can get it.
Many users are behind firewalls, NAT devices, and other obstructions that
prevent them from supporting incoming peering. Whatever p2p features we
create should be usable through the server also (if the particular servers
involved support it) and supportable when only one party can support
incoming connections.
Another key part of this is supporting intelligent communication between
multiple applications on the same or different devices that 'represent' and
are being controlled by the same person. I'm working on a plan for that
also. This is, to some degree I haven't determined yet, like being a
message broker. We might even want to integrate other message brokers in a
clean way.
We need to keep in mind the wide variety of applications that could use this
kind of ability and determine a neutral but flexible set of features that
things can be built on.
One to many and many to many are usually best handled by a server or proxy
of some kind, but there are exceptions to this.
Ideally the protocol used for this would be identical to the main Jabber
protocol.
sdw
Sunir Shah wrote:
> > Well, most of ICQ is peer-to-peer, whereas with Jabber everything goes
> > through the server.
>
> I think a lot of people, including myself, are thinking about
> a peer to peer Jabber protocol. Who else is interested? I'm
> aware others are working on this, though I haven't spoken with
> them yet.
>
> My loose plan was to use messages through Jabber server to
> synchronize, negotiate, etc. the peer network, and then open
> up a *Jabber* stream to the peer. Since a Jabber XML stream is
> an event stream, it's easy to merge both the server event queue
> and the peer event queues together into one event queue which
> the application then services blind to the origin socket. In
> that way, only the connection layer needs to change (aside
> from the negotiation protocol).
>
> Doing this with one peer to another peer is easy. Doing this
> for something like groupchat would be less easy. But that's
> absolutely critical as well.
>
> For small networks, a complete network topology would be the
> easiest and more efficient. But for a large network, that would
> quickly overwhelm each peer with socket connection management
> and traffic.
>
> I'd have to read up on the distributed computing journals to
> know what a robust, efficient, dynamic network protocol would
> be. Maybe someone else knows?
>
> Also, with the Jabber server, we have an advantage. This space
> is above the peer network, and more robust. Consequently, it's
> much stronger than most of the distributed computing models I
> know.
>
> SS
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
--
OptimaLogic - Finding Optimal Solutions
Web/Crypto/OO/Unix/Comm/Video/DBMS
sdw at lig.net Stephen D. Williams Senior Consultant/Architect
http://sdw.st
43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax
5Jan1999
More information about the JDev
mailing list