[REBOL] Re: Shortage of network connections
From: sqlab:gmx at: 18-Mar-2002 8:57
Holger,
thanks for your reply
Unfortunately I am not totally convinced.
> On Fri, Mar 15, 2002 at 01:21:05PM +0100, [sqlab--gmx--net] wrote:
> > Hello
> >
> > I am using Rebol since a few years for transferring messages between pcs
> and
> > not so common systems, where i wrote the servers on the non-pc.
> >
> > Just since short time i use it too for transferring message via Tcp/Ip
> > between pcs. And there I observe connection errors in more than 10% of
> every try.
> >
> > Of course I handle that and try it again. But i can see a whole stack of
> > orphaned socket connections and I am therefore worried that I will get a
> buffer
> > or socket shortage or similar problems sooner or later.
> >
> > Has anyone seen the same effect and what can you do under Windows (NT,
> 2000
> > a.s.o.), to overcome the problem?
> > Should I use another open/mode, but open/binary with Rebol, or are there
> > some tweaks forcing Windows to do a housekeeping on socket connections
> in
> > CLOSE/WAIT state?
>
> Having a socket in Close/Wait for an extended period of time is the result
> of
> bugs in the kernel, either on your end or on the other end. There is
> nothing
After closing Rebol all orphaned sockets in CLOSE/WAIT are gone. It seems,
that Rebol frees all used TCPT/IP resources, even if it does not report all
sockets to the requesting application.
> you can do about it, but it should not be harmful either. Kernels can
> handle
> tens of thousands of socket connections, and connections in Close/Wait do
> not
I expect my applications to run for months without manual intervention, and
yes, there are easily a few hundred thousands opened and closed sockets durig
the lifetime of the application.
> count towards the per-application socket limit, so applications should not
> be
> affected. (Contrast Close/Wait to Time/Wait, which is completely normal,
CLOSE/WAIT should mean, that the other side closed the connection (it's in
CLOSE/WAIT2) and is waiting for me to close my channel. In former times and on
other systems I got problems when closing a listening socket, where some
derived CLOSE/WAIT2 sockets still existed. Then I could not open immediately
after a listening socket on the same port.
So even I am not in trouble now, I also don't want to block peers.
> necessary, not the result of bugs, and only last for a minute or so).
>
> All of this is unrelated to REBOL or any modes/options set in REBOL.
Rebol gives an connection error to the application, either because the
former closing was unsuccessful, but the error was delayed, or because the TCP/IP
stack finished the connection successfully, but Rebol did not wait long
enough to get all connection informations.
Of course, there could also be an error in the peer software. As soon as I
get a hand on it, I will check this too. Maybe it accepts a connection and
cancels it immediately. But why should someone do this. And if, then I would
expect a successful open and a failure later.
Anyway, I think, I have to clear this, before using Rebol for the intended
purpose.
AR
