On 28/11/03 11:37 am, "Richard Dobson" <[EMAIL PROTECTED]> wrote:
>>> 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. Well, I think it is better to solve the hard problems up front. We are talking conferencing, not audio chat. It gets a big deal when you include video. If we get the framework right for audio then an audio-video environment is just a bigger datastream but the bandwidth gets lumpy...so better to ensure the bandwidth is properly considered. I am a bit of a tartar when it comes to what name we give. If this is audio chat protocol then I will shut up as it is a different problem domain. > >> 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 No, you are really missing something - all the other people in the conference! For 7 members it is 42 audio OUT channels buzzing around with each client dealing with the mixing of the 6 they are listening to/being sent - and do no assume that we have a windows system, and one that is likely to have that ever-changing conveyorbelt of proprietary protocols from 'Dandruff Bill'. [ I have combined replies as we seem to be having a similar problem here as a p2p conf!] ;-) Tim _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
