We Keep Coding

SSE or WebSockets for Stackoverflow-like instant notification

What is the best technology to use if I want to make instant user notification,
like StackOverflow has?
I consider SSE and WebSockets. What are pros and cons of each solution?
Should I use socket.io or better to use WebSockets directly?

The main difference is that with SSE you can only receive messages from the server. You cannot send messages to the server. Everything doable with SSE is doable with WebSockets. But not vice versa - WebSocket is capable of sending data to the server. So from that point of view WebSockets win. I can't really see any advantage of SSE (perhaps performance?), but then again I don't have much experience with it.
Note that StackOverflow uses WebSockets. They might have some fallback for older browser, I don't know about that.
As for the third question: perhaps you should ask what language you want to use in the first place? I've been working with WebSockets and Python and it worked really well. You could work with WebSockets directly. The advantage of using socket.io is mostly the fallback (assuming it matters - it does not IMHO): if WebSockets are not available it can automatically switch to other ways of communication (like Flash or long polling). The disadvantage is that it is Node.js (in the sense that you have to restrict yourself to one language) plus there are some performance issues, i.e. socket.io does not scale well beyond one machine.

You might consider using a library like SocketIO that abstracts out the transport layer, so you don't have to worry about the mechanics of how the real-time connection is maintained. This will save you a TON of headaches.

html5 multiplayer advice

I hope this is okay to ask here as its more a request for advice than a technical problem.
I have been developing a game using html5+js and my goal was to make it multiplayer. It's a dungeon crawling game and my intent is to have a main village where all players online and in the village can see each other going about and talk and form parties but when a player enters a dungeon its a seperate instance for them and their party. Party size maxium of 4.
My intention was to use websockets and write a server in c#. The problem is I just found out that IE does not support websockets and is still holding around 25% of the browser market share.
my options seem to be to use websockets anyway and cut out the IE crowd or maybe drop multiplayer support. Someone else suggested that I just write world data to a database and have players read from it every frame and update that way.. it sounds horriable.
I found this socket.io thing that seems like it can use websockets OR do the same deal in other ways - but how does this effect me writing a server? If I use the c# implementation of websockets and socket.io will IE users be able to talk to my server?
Or there may be other ways of doing client->server communication that I don't even know about.
To be completely honest i'm tempted to drop the multiplayer idea! But before I do I look to you guys for advice and experienced suggestions on how I could handle this. Thanks for your time and I hope this kind of question is okay here :)

Do not drop the multiplayer idea! It's way cooler with multiplayer. :)
Socket.io is a Server-Side JavaScript library. This means that you need Node JS server for it. IE users will be able to talk with Socket.io server, because it uses other protocols if WebSockets are not available. For example: FlashSocket or XHR long-polling. The last technique is available in every browser that supports XHR, but it is inefficient.
The greatest advantage of socket.io is the fallback. You can set it to start with any protocol (like WebSockets) and if the client does not support it, then it tries the others. It is really great, since you can use WebSockets (which will slowly but surely dominate web apps) and still work with browsers which do not support it, like IE or Opera or Safari. I don't know whether there is any other library with this advantage.
I don't know any library for real-time connections for C# (I'm not a C# developer), but it is unlikely that there are none (look at this question). Also note that real-time connections require a bit different server architecture then normal HTTP requests, so probably you will need additional server for handling them.
Also I think that neither nginx nor Apache handle WebSockets (without some hard core tricks) at the moment (but Node JS does!). I'm not sure though.

There is no reason to lock yourself in platform-wise for something as simple as transport. Support for these things change over time, and you will want to decouple yourself from them as much as possible. You are, after all, making a game, not a network tech demo.
Have a look at Orbited/Orbited2 TCPSocket. You can write your server as standard TCP in whatever manner you like. This also makes life easier if you decide to make a native client.

Is there a high-level inter-process communications API that is implemented in both C++ and Javascript

I am working on app where I need to pass messages between a C++ application and a Javascript web app.
Certainly I could write sockets code myself in either language and I have done this in the past when necessary.
What I would really like is a higher-level message posting or message queueing API that does a lot of the work for me. Does anyone know of such an API?
I have looked at ICE, and it doesn't appear to have Javascript bindings. I have also looked at Boost message queue, but it only caters for the C++ side of things. If necessary I might roll my own Javascript bindings for either of these technologies.
UPDATE: Sorry should have mentioned this before, I want to run this in a browser.
To give a more complete story what I want is a simple browser-based app that is used to configure and display logging for a C++ application.
I know there are other ways of doing this, but I am specifically interested in a high-level library in both C++ and browser-based Javascript that builds a message queue ontop of the sockets API (if there isn't one then I might consider implementing it myself and writing up a code project article).
ALSO: I'm not bothered about portability in terms of the web browser. Eg if there is a high-level IPC Javascript library that only works in Chrome, I'll be happy with that.

With JavaScript I assume that you are running it in a browser? In this case your C++ application needs to provide a webserver and some kind of JSON based webservice that you can call. On the JavaScript side you just use AJAX to communicate with that webservice.
An alternative would be websockets which might be a little harder to implement on the C++ side though.

To simply answer your question: No, there is no IPC implemented in ECMAscript out of the box.
But you actually answered you question already. If you try to communicate with Javascript that runs in a browser, you indeed should use (web-)sockets connections to pipe date in either direction. Of course you could write a simple HTTP server in C++, but I guess that is overkill and does not have the capabilitys of bi-directional sockets.
It's still some work to implement a web-socket connection in C++ from the scratch (the specs were in flux for a long time), but I guess there are some librarys out already.
If you're trying to communicate with node.js, this is an almost trivial task using real sockets/pipes.

I have found a solution that meets my needs. It isn't exactly perfect but I think it works well enough.
Some people suggested using HTTP and ajax. That turned out to be a useful idea and after some prototyping I think it solves my rather basic needs.
To be more specific I am using the Mongoose HTTP server embedded in my C++ application and I am using the jQuery ajax function to pull data from the server. The jQuery client polls the server continously for new data, not particularly efficient but I think it will do the job good enough for me.
Once my implementation is complete I'll write an article explaining how to do this in detail and then I'll update this answer.

You could try DBus, it has very simple mechanism to define, query and use interfaces, and there are some components for XPCOM and webkit based browsers (for example http://sandbox.movial.com/wiki/index.php/Browser_DBus_Bridge and http://code.google.com/p/v8-dbus/). Also DBus is opensource and cross platform.

For a server side or non-browser implementation how about named pipes?
Yes it's vintage technology and the usage depends which OS you use, but as long as your server side js environment has ability to read and write files it may work, and it fits the description 'high-level' inter-process communication.

Socket Server in Javascript (in browsers)?

I wanted to be allow users to play p2p in a multiplayer game that I'm developing, but to be able to do that, javascript needs to be able to create a socket server in the browser. Is that even possible? I don't know of any API that let clients connect to other clients in javascript. Is there any other way? Like using a hidden flash element?
I am asking for something that doesn't require a server at all. The packets need to travel from client to client directly

In short no, p2p in a browser is not possible.
The closest you can get is using NodeJS (for potentially p2p JS) or a centralised server (or several servers) and websockets (for sockets in a browser)

This question is old, but I can now give an answer: YES, there is finally a way to do p2p communication between browsers!
Thanks to the new standard WebRTC, modern browsers got support for Data Channels, something much more powerful than WebSockets.
Take a look here:
WebRTC Data Channels
Online Example: Banana Bread 3D is a First Person Shooter game compiled to JS+WebGL, using WebRTC data channels in multiplayer mode:
BananaBread 3D Multiplayer online fps game

Interesting question, but probably a duplicate:
What techniques are available to do P2P in the browser?
i know for sure this can not be done using only javascript(in every browser). According to another answer on Stackoverflow in above topic you might be able do this using rtmfp-api.
This project expose Rtmfp protocol (provided by Flash version 10) to
javascript application throught a hidden flash applet. The protocol
allow multiple clients to communicate directly. See the references for
more details about the protocol.
Looking quickly at the site you still need a rtmfpUrl-server in the middle, which i totally understand because the clients need to be be able to find each other(IPs). But I assume after that it will be p2p. Doing a quick search I also found open-source rtmfp-server(s).
I haven't tried this out myself, but I maybe this will help you achieve your goal.
Some other links:
https://stackoverflow.com/search?q=browser+p2p
https://stackoverflow.com/a/7933140/11926
https://stackoverflow.com/a/5211895/11926
https://stackoverflow.com/a/5023048/11926

While this is a shopping question, i'd look into APE
http://www.ape-project.org/
At the very least you could check out how they've structured it.

In order to implement such a game, your JavaScript client must communicate with the server. The server then runs the game logic, and sends the result back to the client.
JavaScript receives user input and sends it to the server
Server ensures that the input is valid (to prevent cheating) and updates the game with the new input
Server periodically sends the game state to JavaScript (either by long polling or by having JS request it at an interval).
Basically, never trust anything coming from JavaScript as it is extremely easy to modify. Everything should be done server-side.

Here's a solution with mobl (but I haven't tried it yet).
http://zef.me/3391/moving-the-server-to-the-browser

It is possible to go serverless with Flash. This is doable with Adobe Flash's Peer to Peer capabilities. I once wrote a peer to peer chat with it. The drawback is Actionscript is a dying language and may not be supported much in the future.
Here is the raw class.
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/NetGroup.html
Here is resources if you don't want to write your own.
http://www.as3gamegears.com/category/multiplayer/
If you want a Server option that is light on the server side. Try this node.js extension.
http://socket.io/
I recommend using a java socket server of some sort. Electroserver used to be one of the leaders in the field, it had Unity support and was scalable to hundreds of thousands. Although I think they have fallen on hard times. The Electroserver site has not been accessible for sometime. I know there are others out there but Electroserver is the only one I have used.

Real-time bi-directional JSON-RPC communication over HTTP

I am building a JSON-RPC server that accepts requests over HTTP. I would like to support bi-directional communication (both client and server can send requests), the specific use case being a publish/subscribe architecture where a client sends a subscribe(X) request and receives changed(X) requests in (almost) real-time. As far as I know, there are several ways to implement this with HTTP:
long polling
WebSockets
polling calls using a cookie-based session model
streaming (keeping the HTTP connection open)
a combination of some of the above
What I'm looking for is a solution that is based on accepted internet standards (if possible), usable from a web browser and easy to work with on the client side. So far, I favour the streaming thing (Twitter, CouchDB do it that way), but I'm not sure about how well this is supported within browsers and JSON-RPC libraries. Also, there may be other ways to do it that I'm not aware of.
Thank you in advance.

I think you should have a look at socket.io to accomplish your task. You could if you wanted to watch this video from the author: "Socket.IO Workshop: Guillermo Rauch". It is easy to work with on both server as client. I have created a simple sample pubsub using redis on top of socket.io.

To my knowledge, Streaming is supported by FF, Chrome (Has bufffering issues that require a datatype of application/octet-stream or a prelude to work) and IE8 (through a little XDomainRequest). I don't know about opera.
I don't really know of any comet industry standards, the Bayeux is probably the closest. It's hard to see how facebook/gmail/twitter do it as all the code is obfuscated, and it's exceedingly difficult to find much info on how all the browsers handle everything.
Even more difficult is that you will need to use a specialized server, keeping this many connections open will require thread pooling etc.. A normal server will blow up pretty fast.
It is a very powerful design if you can get it to work reliably though.

You should take a look at JSONRPC-bidirectional.It supports bidirectional RPC over WebSocket, Worker, WebRTC and HTTP and it is highly extensible.

If anyone is interested in a Java implementation I just wrote a sample app and a blog post about it. It uses Java, Maven, Comet, Bayeux, Spring.
http://jaye.felipera.cloudbees.net/
http://geeks.aretotally.in/thinking-in-reverse-not-taking-orders-from-yo