Architecture decision for client-server communication protocol

This question is pretty generic actually, but I'm really having trouble finding a good answer or example of how it should be done.

We are writing a simple multi-user collaborative web browsing application and we are having some issues deciding what to use for a communication protocol. We are developing in C# under Mono, hoping to eventually make it cross-platform.

The communication would probably consist of messages such as: registering as a user on a session (client to server), notifying clients of a new user who connected (server to clients), requesting a page load (client to server), etc. The ideas we have so far开发者_JAVA技巧 are:

• XmlSerialization of extensions of a base Message class

which we have been trying but are having trouble using the XmlSerialization mechanism as a means of passing data in time, so we're having doubts it's a right way to do this

• Binary serialization in the same case

which I don't really like because of the form the data takes, and because I'm afraid it's a bit more risky.

• Google Protocol Buffers

• WCF

both of which sound much closer to what should be used, but we're afraid it would be overkill for such a quite simple protocol.

and possibly others that I've missed.

What would be a good clean way to do this?

---

WCF - gives you a platform.

THen use JSON and REST for the actual API (options you can use in WCF). This way you can basically "natively" work in javascript.

WCF is great tool wise (sadly, mono most may be too much behind for most of it - not sure), including generating javascript proxies on the fly for your server side interfaces.