I can't speak for all implementations obviously, but the client side coding for jwebsockets caters for the sort of disconnects you describe. Once you make the connection, if it disconnects unexpectedly then it will reconnect automatically as soon as it can. It will then process any events that are pending (optionally). It should cope with the "going through a tunnel" scenario. Of course, if the connection has suffered a more permanent problem, all bets are off (stateless or not).

Since I am dealing with an intranet function it is not such a problem for me.

On 12 Jul 2012, at 02:44, "Richard Schoen" <richard@xxxxxxxxxxxxxxx> wrote:

When you open a web socket connection and leave it open and drop offline, wouldn't you think the Websocket would timeout on next attempted use ?

I haven't played with Websockets yet, but I don't think it would be reconnected automatically.

Now of course I haven't read up on Websockets yet, but I visualize it similar to disconnecting from the wall for a minute and losing a Telnet or FTP connection.

Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT

------------------------------

message: 7
date: Wed, 11 Jul 2012 17:20:35 -0500
from: Scott Klement <web400@xxxxxxxxxxxxxxxx>
subject: Re: [WEB400] Websockets on the IBMi

Hello,

I'm not Nathan, but I'd like to offer my opinion (below):

On 7/11/2012 5:03 PM, Kevin Turner wrote:

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 details he described in his message sound EXACTLY like keep-alives in a TCP connection. In other words.. I agree with you, Kevin, what he's seeing is normal TCP data, a part of the TCP protocol that nearly all communications on the Internet are built upon.

I completely agree with your assessment (not quoted for brevity).
Polling is not an efficient substitute for a server having the ability to push data to the client... A persistent technology like Websockets is going to be much more efficient.

I do think it's important to limit the use of technology like websockets to situations where a server-to-client push is required, and not to use them for other things (i.e. they are not a replacement for AJAX!)

But... in the right circumstances, websockets are an exciting technology!


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

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.