Message-ID: <3236D9D3.2E37@mail.amsinc.com>
Date: Wed, 11 Sep 1996 08:25:07 -0700
From: Tom Hawker <thawker@mail.amsinc.com>
Organization: AMS, Incorporated
X-Mailer: Mozilla 2.02 (Win16; I)
MIME-Version: 1.0
Newsgroups: comp.lang.smalltalk
Subject: Re: VW SocketAccessor Problem
References: <3235BCA2.3AE4@ece.miami.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: thawker.amsinc.com
Lines: 44
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!news.duq.edu!newsgate.duke.edu!news.mathworks.com!news-peer.gsl.net!news.gsl.net!swrinde!howland.erols.net!newsfeed.internetmci.com!in2.uu.net!dns.amsinc.com!

Eric Rizzo wrote:
> 
> I am having a problem with the SocketAccessor class in VW.
> I have a client/server setup, where, one a connection is established,
> the server repeatedly waits to receive data on the socket connection
> (blocking).  Now everything works correctly, but when the client app
> (which happens to be written in C++) exits abnormally (i.e., without
> closing its end of the socket connection), the server (written in st)
> doesn't detect that the connection is lost; it stays blocked in the
> receive.

I have been working with SocketAccessors for 5 or 6 years and have seen
the problem you described only under very obscure circumstances, which
really amounted to a network interface/implementation bug in the O/Ss.
I therefore suspect the problem may not be VW, but is in the lower O/S
networking levels.  When your C++ app dies ignominiously, the associated
I/O channels, including sockets, should be closed automatically, but I've
noticed that Windows et al sometimes hiccups here.

I am assuming you are using TCP, not UDP.  UDP does not make connections,
hence when your C++ app dies you'll never hear about it.  UDP works best
if you use the timeout facilities.

You have to be careful about the one-sided connection shutdown capability
in SocketAccessors.  For some O/Ss, notably OS/2, if you shutdown the VW
transmit side on the client making the request, the server reads this as
a termination (rather than an EOF) and terminates BOTH sides of the link
on the server.  This happens at the network level, so you don't see it at
the app level until you try to write a response.  The client, however, may
not be notified by the server network code that the connection has been
logically severed, and so waits forever.  This seems to be a logic error
in handling event posting, where the Smalltalk app loses the notification.

You can get around this by programming timeout waits into your use.  In
order to continue to support streams over TCP connections, I subclassed
SocketAccessor to build in timeout and retry logic for I/O.  What I did
was override the general readInto:... and writeFrom:... methods to use
the "NoFail" variants, but instead of waiting forever on a semaphore, I
used the wait variant that supported a timeout onto the same semaphore.
For the obscure network case above, immediately reissuing the read into
the VM would detect the EOF condition, and the accessor would shutdown
in a normal fashion.

> ANY advice or experience would be gratefully accepted.
> If possible, respond also to my e-mail address.

(Sorry, but EMail posting doesn't seem to be working.  We've got a funny
EMail setup with Lotus Notes using CCMail as a gateway...)

Tom Hawker
tom_hawker@mail.amsinc.com
