Re: Websockets on the IBMi

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.
--
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.