From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f753e,97d2772750ae15ad
X-Google-Attributes: gidf753e,public
X-Google-Thread: 103376,97d2772750ae15ad
X-Google-Attributes: gid103376,public
From: tim gilbert <timothy.j.gilbert@boeing.com>
Subject: Re: Extended comm loss and TCP/IP
Date: 1999/04/15
Message-ID: <37163723.BD95C589@boeing.com>#1/1
X-Deja-AN: 466846579
Content-Transfer-Encoding: 7bit
Sender: nntp@news.boeing.com (Boeing NNTP News Access)
X-Nntp-Posting-Host: 130.38.128.244
References: <37142321.E3B0C8BE@pacbell.net>
Content-Type: text/plain; charset=us-ascii
Organization: The Boeing Company
Mime-Version: 1.0
Newsgroups: comp.lang.ada,comp.object.corba
Date: 1999-04-15T00:00:00+00:00
List-Id: <comp.lang.ada>

For some info do "man setsockopt" and "man 2 socket" and read the parts
about SO_KEEPALIVE, I've been told that without SO_KEEPALIVE being set
that the client would remain blocked at the recv call forever.
Hope this helps.

Tim

Mark McKercher wrote:
> 
> I'm having the following problem.  We're using Ada95 on both Solaris and
> HP-UX and our orb is ORBexpress.
> 
> I'm working on a project on which a client workstation might be a
> satellite link away from the server.  Loss of comm may be frequent and
> sometimes last tens of minutes at a time.
> 
> Normally, if we issue a CORBA request while comm is down, we'd see a
> COMM_FAILURE exception.  I can deal with that.
> 
> If comm is lost while in the middle of a CORBA request, if comm is
> re-established within a reasonable time, then the  request will complete
> normally.  I can deal with that too.
> 
> If comm is lost while in the middle of a CORBA request and it takes 10
> or more minutes to re-establish comm, then there is trouble.  It appears
> as though the server side completes the request but abandons the return
> to the client after 10 minutes.  The client, on the otherhand, is
> waiting infinitely for the return.  Hence, the client side is locked up
> and never frees up.
> 
> Our orb vendor has looked at the problem and has determined that it is a
> TCP/IP problem... it never sends any indication to orb of a problem.
> 
> Has anyone else experienced such problems with TCP/IP and are there any
> workarounds for such a problem?
> 
> Thanks for you  help!
> 
> Mark M.