Nathan
From my limited experience so far, it does seem that if you want to broadcast you have to build in your own filter to specify who to broadcast to (assuming that all connected clients is not desired). So you could create a very efficient filtering mechanism, or a very inefficient one - depending on your skills :) Obviously the latter negates any perceived benefits. There is a discussion about this very thing on the jWebsocket forum. If you have a million connections, and you only want to broadcast to two of them, you need a pretty efficient mechanism for filtering the connections - not easy, given that my java skills laughably inadequate.
At the moment, I am not using the broadcast technique at all (apart my slider demo - which has no practical purpose other than to tell me that my plug-in code works). I am using an RPC plug-in on the server that accepts a call from the client to say "I can accept calls". The RPC plug-in then waits on a keyed data queue for call information directly relating to that agent/session. When it has one, it performs an RRPC to an authorised javascript function on the client to pop-up the screen. That is a basic summary, although it is a bit more involved obviously.
So I am effectively hanging a thread in the jWebsocket server. From what you have said (and being cognisant of Henrik's last email) I could just as easily achieve this using normal XHR long waits and not bother with websockets at all. I guess this is what is meant by long polling - in my previous emails I should have just said "polling" - not "long polling" (Thanks Robert).
I am still sure there will be many practical purposes for websockets, but it is early days for me. What I have learned during this discussion is that for the CTI problem I wanted to solve, websockets are not the only option. It has been a very valuable exercise so far though.
Kevin
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: 12 July 2012 14:06
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] 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.
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.
NOTICE: The information in this electronic mail transmission is intended by CoralTree Systems Ltd for the use of the named individuals or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone, so that the sender's address records can be corrected.
--------------------------------------------------------------------------------
CoralTree Systems Limited
25 Barnes Wallis Road
Segensworth East, Fareham
PO15 5TT
Company Registration Number 5021022.
Registered Office:
12-14 Carlton Place
Southampton, UK
SO15 2EA
VAT Registration Number 834 1020 74.
midrange.com
