Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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