<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: RE: CIPE-Win32 transfer hangs
From: Jan Olderdissen <jolderdissen,AT,ixiacom,DOT,com>
Date: Sat, 9 Mar 2002 19:23:59 +0100

As I understand it, the WSAECONNRESET is a transient error that occurs
whenever a "port unreachable" ICMP message is received on the listening
port. What's wrong with "resetting" the connection right then and there by
closing the socket and reopening it? None of your managing structures would
have to know about it.

I will test your new code as soon as I untangle myself successfully from
domestic chores. :-)


-----Original Message-----
From: Damion Wilson [mailto:dwilson,AT,ibl,DOT,bm
Sent: Saturday, March 09, 2002 09:29
To: Sandino Araico Sánchez
Cc: Juan Antonio Ruiz Zwollo; cipe-l,AT,inka,DOT,de; Jan Olderdissen
Subject: Re: CIPE-Win32 transfer hangs

In which case I have a major problem. Here's the dilemma :

The socket read routine wants to queue a read request that will get
later on, i.e. when the peer eventually sends an unsolicited packet.
the read request returns a WSAECONNRESET status which I (must) ignore if I
ever going to successfully queue the read request. If the socket has indeed 
become invalid, I will continue to get this status back and never queue the 
pending read.

If this is so, then Windows sockets is more flawed than I thought because it

would require that I dismantle the socket and its managing structures.

The pre11 I released last night ignores the WSAECONNRESET's so try it out 
guys and tell me if it goes into an infinite loop there. If necessary I'll 
put a status message there.

I hate this. Datagram sockets are not supposed to maintain any connection 
state because they are connectionless. There should not be lingering
between SendTo's and RecvFrom's. Period.


On Saturday 09 March 2002 12:29 am, you wrote:
> Jan Olderdissen wrote:
> > This is making more and more sense. I haven't tried to log the error
> > as you suggested because the machine I can do this on is not currently
> > hooked up to anything. However, check out the return code WSAECONNRESET
> > from WSARecvFrom(). The description states: "The virtual circuit was
> > reset by the remote side executing a hard or abortive close. The
> > application should close the socket as it is no longer useable. On a
> > UPD-datagram socket this error would indicate that a previous send
> > operation resulted in an ICMP "Port Unreachable" message."
> Ok. This enforces my suspect that the Windows cipe is sending a small
> packet which kills the Linux cipe. The Windows cipe is not able to
> differentiate between the other end being dead and UDP packets being lost
> because of a network problem.

<< | Thread Index | >> ]    [ << | Date Index | >> ]