Re: Websockets on the IBMi

I now see that I was wrong about Web Sockets using a request-response protocol just like XHR. It helps to use the right Wireshark filter:

Filter: ip.addr == 83.169.11.55

No, Web Socket clients evidently go into "listen" mode after a connection is established, and the Web Socket server can just stream data to them as events occur. The Kevins were right about it being a bi-directional protocol. Servers broadcast messages to client listeners at will. And the messages don't have HTTP headers, so a Web Socket interface is significantly more streamlined.

My only caveat to the efficiency advantage of Web Sockets is that various sources say that compression is NOT in the specification. You can configure the HTTP server to compress data streams using g-zip; a 250 byte data stream may be compressed to 40 bytes, for example. That helps in low-bandwidth scenarios. I'm doubtful about Web Sockets using data compression.

With respect to jWebSocket, I confirmed that broadcast messages are sent to all "listeners" on the port. In the demos, Chat clients receive messages generated by Canvas clients and visa versa, evidently because they are all listening on the same port 8787.

There's a couple problems with that. First, you'd evidently have to write client code to filter out messages not intended for your client. And it voids the efficiency advantage when all messages are broadcast to all clients. I'm hoping that Kevin Turner will confirm this.

In a call center scenario I can imagine cases where some employees take calls for one customer while others take calls for other customers. If all calls are broadcast to all listeners, does the Web Socket client just filter out those not intended for them?

I'm interested in broadcasting messages to HTTP clients to support virtual meetings. I wouldn't want messages from one set of meeting participants being broadcast to participants of other "meetings". No, meeting should be private.

-Nathan.