|
Nathan
From my limited experience so far, it does seem that if you want tobroadcast 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
