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.
Yes I agree, the concept is unproven. There is a trade off between high
initial session start cost vs. no cost during session. I will consider
your suggestion. Maybe we will start with non P2P and as the load goes
up and we understand the usage statistics, we can considering
incorporating P2P in next version of client.
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.
I was more considering using TCP (port 80) rather than UDP to avoid all
these issues you mentioned. I am certainly not going to write networking
stack just for a chat client.
I have an idea of what I am up against. As well as little surprised that
nobody tried P2P for chat. I will reconsider my options.
Thanks for help
Ravi
