× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.