> > 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. > > If I were initiating a conference (ie I was the server) and I lost my > connection d*mn if the rest of the meeting can rattle on without my hearing > it. It might be OK for Xbox but in a business environment it is very > important to have all members around all the time and especially the > Chairman!
Then in business you use a server or use a reliable connection, for a group of friends chatting away between themselves it is bad if everyone gets disconnected, also if its not a meeting and people are going in and out of the chat what if the person acting as the server goes ?? Everyone will get disconnected. As already noted anyway this p2p mode is primarly for normal people anyway, business's will most likely host a server, whereas home users will generally not have access to one, also as already shown the client acting as a server approach as some major downsides on unreliable/home connections. If I was chatting away with my mates from home I would be mighty annoyed if the whole chat ended when one of my mates (the one acting as the server) started experiencing network problems, especially if I could have used p2p and still continued chatting with my other mates while the one with problems got it sorted and rejoined later. > As to bandwidth, unless I am missing something each peer needs to send out > their audio to each member - 7 people means 6*7=42 streams out. With a sever > you have 12 streams to the 6 clients - one out and a mixed one back (sans > your own data). Even if the output stream is broadcast, with p2p each client > will have to mix those 6 streams so it is almost the server anyway! With a > server based solution the client only has a single stream in and out to > handle and the server is the only one doing the donkey work and technically > not much more than a client would do in a p2p environment, which is logical > as in p2p each p has to be a server in anything but name. Yes you are missing something 6 people will mean 6 streams in and 6 streams out on each client, meaning 12 streams on each client, which is only 48kbps each way assuming an 8kbps voice codec is used, which a broadband connection will easily handle, also remember using silence detection it means that only connections with people currently talking need even have traffic flowing so that bandwidth use will likely go down to 8kbps normally inwards when someone else was talking and only sometimes jumping up to 48kbps if everyone starts talking at once, also the outgoing bandwidth of my connection will only be used when I myself am talking. Also on the subject of mixing those streams on the client, yes those streams will be mixed but that task certainly on windows systems can be passed into directx which will pass most of the donkey work of that onto your soundcard, whereas in a server where the mixed stream needs to be rebroadcast that needs to be all handled by the processor, and as well as the stage of actually mixing the streams the server also needs to reencode the mixed stream to send out, so the p2p mode does infact put less demand on the system as far as mixing goes. Richard _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
