Trying to Understand Web Sockets

What language is used on the server side of a Web Socket connection?

[frobozz]

Please pardon me if there is a better forum category for this; nothing else looked appropriate to me.

I'm trying to simply understand web sockets at a high level. Not actually implementing them, just want to grasp the rough nuts and bolts. I see tutorials all over the web, but one very simple question I cannot seem to get answered is this:

How does the server side of a web socket connection parse the data it receives?

With AJAX, we can use PHP and extract our info from GET or POST data. But how does it work with web sockets? From what I've seen so far, it looks like PHP is not / cannot be used with web sockets.

Anyone here have more information about this? My goal for now is to simply determine whether web sockets will be a viable alternative for a proprietary software-as-service system that I manage.

[phranque]

it's actually an IP socket, so it's happening at a lower level than a specific protocol such as HTTP (web).
part of the protocol definition is the port(s) used by the protocol, the type of communications, handshaking, recovery, etc.
between the application layer (HTTP) and the internet layer (IP) of protocols, there is a transport layer (TCP).

PHP should be able to handle socket programming.
depending on what you are trying to accomplish it is likely there is an existing protocol at a higher level that will work for you.
for example, if your service is a message-oriented or presence information application, you might use XMPP.
you can also find PHP libraries to support XMPP.

[daveVk]

it's actually an IP socket

Seems to be a bit more than that, Googles answer to ajax ?.

[tools.ietf.org...]

In any case, not supported sufficiently, at this stage, for general use.

[phranque]

thanks for pointing that out, daveVk!
so new i've never heard of it.

In any case, not supported sufficiently, at this stage, for general use.

i would agree with that assessment at this point.

[rogerfgay]

Although there are times when you will be able to use websockets instead of Ajax, they are not a replacement for Ajax. They are not proprietary or the product of a single company (for example Google). Websockets are defined by an international standard (now in last call status) and bundled with HTML5, so to speak.

Websockets (along with other HTML5 improvements) will revolutionize browser GUI web applications. You can do request-response, just like Ajax, but the connection remains open at both ends until one side decides to close it (servers will not ordinarily close it unless the client requests close or in response to a technically malformed message . suggesting a security breach).

It's bidirectional all the time. The server can send a message to the browser anytime it wants - not just in response to a request. It's not going to be a simple point-click-get world anymore. It'll be much easier to build real web based interactive applications with a browser as GUI.

I'm building a websocket server in Java: [highlevellogic.blogspot.com...]

[rogerfgay]

There is something I should definitely add re_: the difference between Ajax and other http methods. Websockets are built on http. The first header in a websocket connection request is an http header and the other header information is in the same form (although newly defined keys). One of the keys requests an upgrade to websocket.

Since that gives you a continuously open connection (until you close), you don't have to send the header to request connection every time you want to send a message to the server. The header for each message is much more compact. That means much less stuff flying around the Internet every day. That alone should move you toward websockets even if you're doing the same kinds of things you can do today with other methods.

Save the Internet! Reduce congestion. Faster, more compact, more efficient communication.

BTW: I'm also building a complete client in Java. You can use websocket communication outside the browser too.

[astupidname]

Excellent first posts, @rogerfgay, and welcome to webmasterworld! It's good of you to point this out:

Although there are times when you will be able to use websockets instead of Ajax, they are not a replacement for Ajax

There will no longer be need for what is known as "long-polling" via ajax, where ajax is used to constantly check the server for new messages/data updates etcetera. So that is where websockets will eliminate the need for ajax. But ajax will still be used in instances where a single transmission to the server and back is needed.
Ajax is text messaging, seems websockets are more like a phone call. Definitely a good advancement which will be used plenty once there is more support and standards finalized.

[frobozz]

Thanks for all the replies everyone. All your answers are helpful, but they don't really address the heart of my question. I've actually done quite a bit of learning since I posted this, and what I've learned so far is pretty disheartening.

I'm plenty familiar with what web sockets are in concept. My question was more about how they are actually implemented. Based on what I've seen so far, I most agree with daveVk -- they are not ready for prime time.

In talking with three different people who are currently developing web socket sites / apps (or have done so), each of them rattles off a laundry list of third-party 'plugins' that are required to get it all working; 'message brokers' here, a listener app there, a relayer there, etc. (And indeed most of them are using Java.)

I despise Java, and was hoping there was some sort of native PHP support. It seemed a natural expectation. I'm told that, yes, in theory, it can be done with PHP, but that seems to add yet another layer to the already convoluted train wreck that's required to get it all going.

From what I can see, until web sockets have evolved sufficiently to where they can be manipulated with the same simplicity as AJAX, they're not ready for mass consumption. This would of course require adding functionality to JavaScript itself, which in turn would require changes to all the A-list browsers.

So I'm not holding my breath for it to occur any time soon.