Kevin,
Your call center apparently runs differently than I imagined. It sounds like the server that receives calls knows precisely which "agent-session" to route calls to. I previously imagined that you might have a pool of agents taking calls for Customer A, while another pool of agents might be taking calls for Customer B. I imagined your server broadcasting calls to various pools of agents.
In my case, I'm interested in broadcasting messages to meeting participants, where an IBM i server may be hosting perhaps hundreds of meeting concurrently, with a requirement to broadcast messages only to the participants of each meeting.
I thought there might be a parallel between meeting participants and pools of call center agents.
Returning to jWebSocket, their Canvas demo enables continuous mouse movement to flood the server with so many messages that it breaks the service. That not only locks Canvas clients. It also locks Chat clients in other browsers. There's some sort of connection with all clients that breaks. Chrome displays it's "Ah, snap ..." message saying that the connection to the server was lost.
Although clients lock up, the jWebSocket server seems to be able to recover from it. Clients can "refresh" their page to recover.
-Nathan.
----- Original Message -----
From: Kevin Turner <kevin.turner@xxxxxxxxxxxxxxx>
To: 'Web Enabling the AS400 / iSeries' <web400@xxxxxxxxxxxx>
Cc:
Sent: Thursday, July 12, 2012 8:18 AM
Subject: Re: [WEB400] 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
midrange.com
