[jdev] Re: help needed to implement a P2P Chat Client
Michal vorner Vaner
michal.vaner at kdemail.net
Mon Aug 28 13:44:31 CDT 2006
On Mon, Aug 28, 2006 at 10:52:56AM -0700, Ravi wrote:
> >Why? How many simultaneous connections do you expect? Do you really know
> >that the existing client-server model won't work? It seems to work just
> >fine for lots of large deployments!
> The goal is to be able to scale to millions of logged in users. I did
> not find any existing scalability numbers for ejabberd, are there any
> load test numbers for ejabberd (or any other server)? Since it is
> reasonable to assume that P2P chat will substantially increase
> scalability and decrease bandwidth requirements. Hence the need.
Are you sure you will save something? Creating the jingle session with
someone is a little expensive for the XMPP stream, there are definitely
more stanzas that one or two messages sent. And you have to keep the
session opened trough NATs, you will be using STUNs of the servers,
which is more load on them..
I think there will not be much gain in doing the chat P2P. I guess it
will be easier for you, and probably cheaper, to buy more servers and
have more domains or some cluster of them, than writing this.
> >No, Jingle is not trying to address this. Jingle does signalling over
> >the XMPP channel and media over RTP or whatever.
> Correct me if I am wrong, as I understand jingle will help establish a
> P2P connection. Once connection is established, I can deviate from the
> specs and use my own protocol for exchanging chat messages. Finally I
> can use jingle again to close the session.
Well, connection is not the right word maybe. You need to take care of
all resends and flow controls and everything from userspace, which is
error-prone. I do not know, if it is already in libjingle (well, I heard
something like that will be in next version), but I really do not trust
it can possibly work as well as in-kernel TCP stack.
Security warning: Do not expose this email to direct sunlight.
It may lead to undefined behaviour, including possible data or life loses.
Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the JDev