Two way Server/Client Communication Paradigm

[M.Jackson]

Ok, so I consider myself to be fairly proficient with programming in general, although I am admittedly new to bi-directional networking. So here I am asking about methodological approaches.

A non-disclosure clause prevents me from giving any details, but I don't think they would actually be pertinent. What is important is that the system must accept input from client side Javascript from many users and disseminate that input (once processed) to a number of users. In a way, think multi-channel chat system (totally different environment, but the mechanisms seem similar).

As I see it, I have two options: periodic server polling, or server-sent events (compatibility with IE is not a requisite).

So, my question is, which method (of these two or even something that I am not thinking of) is superior from the standpoint of server bandwidth?

Periodic server polling obviously seems as if it would send a great many unneeded requests, but my hesitation for dismissing this method is that I don't see any client being idle for any considerable length of time (thus the client will send commands to the server quite often) and it simplifies my server software by delegating that section of logic (which data chunks need to be updated) to client CPU's. Additionally, I can throttle the update period based on server load.

Server-sent events initially sounded like a great idea until I thought about the extreme likelihood of a large number of users (upwards of a hundred) interaction with the same chunk of data, thus requiring that each client receive an update every time another client does anything, which is likely once ever second or two, thus resulting in hundreds of updates being sent to hundreds of clients every second. Sounds similar to a denial of service situation to me.

Anyway, I think I already know what I'm going to do for this project, but thought that this might be a good way to introduce myself to these forums.

[rnd me]

if you can use node.js and socket.io, you can raise events on any or all browsers, or the server, from any browser or the server, with one line of code.

with a very modest server and without multi-instance balancing, socket.io supports about 2500 simultaneous clients, which sounds like more than enough for your project.

also, socket.io abstracts the connection handling and browser compatibility problems, so you get these instant events working in IE6 onwards.

finally, polling by definition means that some clients will be out of sync at anyu given time. the less out of sync you make them, the greater the polling frequency and the more bandwidth used. Socket.io resets a connection every 20 seconds, which is likely too long for a comparable polling script to work. Plus, events don't take 1-19.9 seconds to raise in socket.io; i've personally triggered dozens of browser color changes within ~0.5 seconds, but the claims are much broader than that, and i belive them based on what i've seen.

[M.Jackson]

Although being very good information, I understand that Node.js is a single threaded approach. If this is true then it is unacceptable for my project.

I was actually wanting to talk more about methods of approaching this kind of problem rather than a specific library because I have very specific requirements that rule out using most existing frameworks.

[rnd me]

I understand that Node.js is a single threaded approach. If this is true then it is unacceptable for my project.

out of curiosity, why is that the case?


----
in general, i think long polling provides better user experiences than pings...

[Old Pedant]

Have to agree with RndMe. If you need more performance than node.js will give you, then I suspect you are going to be stuck with creating a custom web server or, at a minimum, custom web server plugin. And maybe with a custom browser plugin (which could be as simple as a Java applet).

But expecting to do this AJAX-style is not viable for the traffic you are contemplating.

[M.Jackson]

out of curiosity, why is that the case?


----
in general, i think long polling provides better user experiences than pings...

To be honest, I don't remember what I was thinking when I wrote that, because multithreading is not yet a requirement and when it does become one I am going to insist on a dedicated box.

Reading about Node.js earlier, there were a couple of things that I did not like about it, like it adds another layer of complexity onto an already very complicated project. The biggest point though, is that it does not obviously give me any advantage over server-sent events while requiring me to go through the extra effort of adding javascript to my php-based server.

My primary interest in this tread has not been specific implementations. More accurately it was the logical reasoning behind these two paradigms, but I think that got lost somewhere.