Are the things you are seeing just normal activity with any TCP/IP socket connection? There has to be something going on at that low level with any permanent connection to maintain the connection status. With respect, maybe you are getting too bogged down in the detail.
The bottom line for me is this (using a real example I have to work on): I have a CTI application. The agent using the browser waits for incoming phone calls and the incoming calls are logged on the IBMi . With an XHR long polling method, the agents browser polls the server every 5 seconds to see if the call information has been logged. If it has, then the XHR returns the HTML containing the customer details screen. So they answer the call and have the clients details in front of their face. It works well, and if they are lucky with the timing, the time difference between the call arriving and the screen popping may be quite small. Most of the time, there is (up to) a 5 second delay between the call arriving and the screen popping up. There is this inbuilt latency with long polling techniques, and for this application it is a serious problem. It directly impacts how many calls they can answer per hour.
With my web socket alternative, there is virtually no latency - ever. As soon as the call arrives, the server send the customer screen to the browser instantly. It doesn't have to wait for (up to) 5 seconds for it to be polled by the server. In order to achieve the same instant response using XHR long polling, I have to reduce the polling interval to something like 100ms. So while waiting for a call, my browser is flooding the server with 600 HTTP requests per second. Multiple that by 1500 call centre agents, and the server is getting 900,000 HTTP requests per minute. The server and the CGI application just dies. With web sockets, I get an instant response and virtually no traffic in comparison.
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of Nathan Andelin
Sent: 11 July 2012 22:46
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Websockets on the IBMi
From: Kevin Turner
You can observe an open WS connection using something like wireshark.
Okay, I downloaded Wireshark and monitored the traffic for the chat and canvas demos at
http://jwebsocket.org
Now I'm more skeptical about Web Sockets than I was before. The Web Socket clients continuously periodically poll the server, even while idle. Lots of HTTP [ACK], [FIN, ACK], [SYN], [PSH, ACK] and Keep-Alive requests. The packets are smaller than those associated with XMLHTTPRequests, but there are a lot more of them, so ultimately you may be transferring more data across the wire with Web Sockets.
Entering "Hello" in the chat service generates at least 300 bytes of traffic; more if a 2nd chat client is listening.
All of a sudden I see a burst of packets flying across the screen even though there has not been any chat activity. The chat client shows "org.jwebsocket.plugins.canvas" messages, even though none of my browser windows are using the canvas demo. That's just weird.
I'm not convinced that the extra 250 bytes of http header data associated with XMLHTTPRequests is more overhead. It gets compressed to 40 bytes if the server has compression on. It takes less than a millisecond to transfer 40 bytes over 2 Mbps bandwidth, which is pretty low bandwidth.
-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
