Using a client/server model has no heavyer requirments than a p2p based mode. Nor is it any complexer, but it will allow much easyer to participate in client/server based conferencing.
If you're argueing that, in the case of more than 2 persons talking, rather than client/server based conferences we should have this all done in p2p mode, I disagree. There's definatly cases where that is intresting, but the need is really for client/server, just like the real need for 2 people talking is a direct connection (wether this is client/server or p2p based doesn't matter).
I also think building p2p based conferincing into the protocol from day one is unnecisarly complex, that should belong in an extention in any case then.
It's odd though, that you completly put aside the arguments you tried to make about 1 on 1 chat, when you talk about conferencing. Namely, limited bandwith (in the case of 20 people talking this would be almost 10 times as much as as c/s based) and lack of mixing capabilities (even if your pocketpc does have that much bandwith it'll have to mix 20 channels!).
On Fri, 28 Nov 2003 10:21:29 -0000, Richard Dobson <[EMAIL PROTECTED]> wrote:
The "server" is just one of the users, it's all on the same JID, etc. This
is ust to keep the protocol uniform and means that if you support 1 on 1,
you also support 1 to many automatically. The only differences is that
rather than having two "peers" with an equal role one is server and one is
client.
It is still isnt really needed to "keep the protocol uniform", you still havent explained why we cant design a protocol that works in both client/server and full p2p with minimum overlap, just keeping on stating that it will keep it uniform doesnt explain it.
>> This allows 2 people to have a conversation through a directconnection.>> One is clearly the server, and the other the client. Wether this stilldo
>> matches your definiton of peer to peer I don't know, but it allows to>> what you want doesn't it?
>
> No not really, it is still placing an unnecessary requirement on one of
> the
> clients, its far better to have two separate modes fully p2p when
> appropriate (when there is bandwidth available)
Bandwith requirments will be *exactly* the same for both solutions.
I wasnt talking about bandwidth requirements, I was talking about the
general requirement for potensially more code (i.e. the client has to have
code for acting as a full server as well as a client) there are also the
processor requirements of mixing the audio in the server client to send out
to the other clients among other things. I was arguing that if the bandwidth
is available on all the clients there is no reason not for going fully p2p.
Any JID can assume the role of server, including your own. So any client
can implement this (that's the point). As explained before, you will not
need any components whatsoever. Indeed you're right, in corperations they
might want that, and as a paid service too maybe. The beauty when you
stick to this mode is that any client designed primarly for 1 on 1
conversations can take part of this!
Yea and any JID can go fully p2p as well, any client can implement it too,
im not sure why you are trying to argue this fact other than the fact that
you can do it, I already know you "could" do it that way im not arguing
that, im arguing that it is not the best way to do it.
Though below I see you're now entering the realm of using P2P modes for conferences, wich is another story..
Thats the whole point I am arguing for fully p2p, havent you realised that
by now?!?!
we> Now just because we have two separate modes > it doesnt mean we cant design a protocol which supports both modes of > operation, I dont know why you seem to think to have a common protocol> need it to only work in a client/server mode (wether there is an actual
> server or a client is acting as a server). The main benefit I see if
> fully
> p2p mode will be that if someone gets disconnected from the net the rest
> of
> the people in the conference will still be able to communicate without
> interuption, but with your method of the client acting as the server for
> the
> conference if that goes offline no one will be able to chat. The Xbox
> live
> voice chat seems to work p2p with silence detection and works fine with
> as
> many as 20 people in the conference. Also the method of going direct p2p
> will help to reduce latency which could also become a problem in server
> hosted chats, SIP seems to work by establishing a p2p connection between
> the
> two endpoints too and the reason apparently for this is to minimize
> latency
> which in voice chats can be very noticable.
And I think we all agree that most needed modes are 1 on 1 without the
need for any intermidiate server and as little trouble as possible with
NATs/Firewalls, and conferencing with a single stream to a central server
that mixes the audio.
You seem to have conveniently skirted the issue here of latency which I
think is a major one, and the issue that other already deployed systems
(SIP, Xbox) use the p2p approach for very good reason and perfectly
sucessfully. You also seem to have skirted the issue that the client acting
as the server is also a major point of failure, if they loose connection
then the whole conference will stop and no one will be able to chat, whereas
p2p will just continue on fine for the rest of the people. There are several
ways the client could loose its connection either internet problems (as ADSL
and Cable broadband are not always that reliable over here in the UK), if
the person is on dialup they might have hit their connection time limit and
been disconnected and have to redial (over here in the UK dialup users on
most unmeatered packages have set limits for the length of time each
connection can be, usually 1-2 hours, at which time they will need to
redial), or someone might not like the person hosting the conference (maybe
they were excluded from the chat) and DDOS's them, in light of these it
shows that your server solution has some serious problems that it cant
really solve very easily.
Not that conferencing with multiple connections isn't intresting, but that
could be done as an extention on top of this.
My point is it doesnt need to be an extension and can and should be built into our signalling protocol from day one, you still also havent provided any credible benefits that outway p2p's benefits.
Not when, like in all the examples I gave for 1 to 1 so far!, your own
client is the server. However, using a client / server model will make it
easier to integrate remote management into the protocol.
It will make it slightly easier but it is not really all that much harder IMO at the protocol level to be able to administrate a p2p setup, it also gives more power to the members of the group to control the conference as well.
Richard
_______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
_______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
