Catalyst Development

Re: Listener refuses connection most of the time

Mike Stefanik — Tue, 30 Jun 2009 21:25:33 GMT

Author: Mike Stefanik
Post subject: Re: Listener refuses connection most of the time
Posted: Tue Jun 30, 2009 2:25 pm

You could do that with a blocking listening socket. I'd recommend spinning up a thread specifically for the job (rather than doing it in the main UI thread), but you could just loop around calling Accept; when it succeeds, spin up a new thread for the client session. You could set the timeout period to be fairly low, a few seconds, if you wanted to track idle time.

Re: Listener refuses connection most of the time

David Rettger — Tue, 30 Jun 2009 21:12:38 GMT

Author: David Rettger
Post subject: Re: Listener refuses connection most of the time
Posted: Tue Jun 30, 2009 2:12 pm

Can I just skip using On_Accept and launch a thread that will create the listener socket, loop while not terminated, and check for incoming sockets? That would probably be the easiest thing to do, assuming I can check socket.accept() continuously without causing problems. (If it were socket.blocking = True, would it just block until a new connection came in or it timed out?)

Re: Listener refuses connection most of the time

Mike Stefanik — Tue, 30 Jun 2009 18:24:38 GMT

Author: Mike Stefanik
Post subject: Re: Listener refuses connection most of the time
Posted: Tue Jun 30, 2009 11:24 am

I'm afraid I don't have any specific code examples for this, but there's generally one of two approaches that you could take. One would be that you create a loop and synchronize the spinning up of threads that create a new instance of the class, calling the Accept method with the listening socket's handle. If the Accept method fails, you would need to signal back to the listener that it should exit the loop and wait for the next OnAccept event to trigger. The other approach (and perhaps simpler, depending on your application design) would be to actually create the new class instance inside the OnAccept handler, call the Accept method with the listening socket handle, and if it succeeds, spin up a new thread and pass that class instance to the thread. If it fails, then you exit the loop. The only caveat with this approach is that you either need to disable thread affinity (by setting the ThreadModel property) or you need to call AttachThread in the new client session thread that starts, so that it "inherits" that instance of the class. The documentation has some more information about AttachThread and the threading models.

Re: Listener refuses connection most of the time

David Rettger — Fri, 26 Jun 2009 21:08:09 GMT

Author: David Rettger
Post subject: Re: Listener refuses connection most of the time
Posted: Fri Jun 26, 2009 2:08 pm

I bet your analysis is correct. One question, though...

Right now when OnAccept fires, we pick up the socket handle from the OnAccept e.Handle parameter. A Session class is created, handle is passed in, and the session class actually calls Socket.Accept.

Would you happen to have a code chunk where you would loop inside OnAccept, calling accept and then creating the class and passing things through?

Re: FTP Error: The networking subsystem has not been initialized

Mike Stefanik — Fri, 26 Jun 2009 20:21:00 GMT

Author: Mike Stefanik
Post subject: Re: FTP Error: The networking subsystem has not been initialized
Posted: Fri Jun 26, 2009 1:21 pm

Internally, that's caused by an error that's reported by Microsoft's Windows Sockets API when the WSAStartup function fails and returns WSASYSNOTREADY. Here's Microsoft's explanation for the error:

WSASYSNOTREADY
Network subsystem is unavailable.

This error is returned by WSAStartup if the Windows Sockets implementation cannot function at this time because the underlying system it uses to provide network services is currently unavailable. Users should check:

That the appropriate Windows Sockets DLL file is in the current path.

That they are not trying to use more than one Windows Sockets implementation simultaneously. If there is more than one Winsock DLL on your system, be sure the first one in the path is appropriate for the network subsystem currently loaded.

The Windows Sockets implementation documentation to be sure all necessary components are currently installed and configured correctly.

Unfortunately that's as specific as it gets, but it's generally related to a failure loading the Windows Sockets DLL or some configuration issue with the TCP/IP stack. There also may be some other unrelated process going on that's interfering with it, such as the system running low on non-paged memory, something along those lines. As far as implementation is concerned, nothing was changed with how we initialize the WIndows Sockets API between version 5.0 and 6.0; that portion of the code is identical.

FTP Error: The networking subsystem has not been initialized

Marcia Cupery — Fri, 26 Jun 2009 18:35:36 GMT

Author: Marcia Cupery
Post subject: FTP Error: The networking subsystem has not been initialized
Posted: Fri Jun 26, 2009 11:35 am

Hi,

We recently updated our software to use csftpax6.ocx. One of our customers who does FTP sends on an automated basis several times per hour (approx. every 5 minutes) has reported that after running for about 5 days, the following error occurs upon attempting to establish an FTP connection:

The networking subsystem has not been initialized

which gets replaced by this error about 50 minutes later:

Automation error
A dynamic link library (DLL) initialization routine failed.

They state this can only be resolved by shutting down and restarting the software. What could be the cause of this error sequence? Any insight would be most appreciated.

Thanks,
Marcia

Re: SSH Key Files

Tim Townsend — Thu, 25 Jun 2009 19:53:37 GMT

Author: Tim Townsend
Post subject: Re: SSH Key Files
Posted: Thu Jun 25, 2009 12:53 pm

Thanks, Mike. Per usual, they are lining up at the gate. No pitchforks yet, but I am sure it is coming. Cheers - Tim

Re: SSH Key Files

Mike Stefanik — Thu, 25 Jun 2009 19:51:50 GMT

Author: Mike Stefanik
Post subject: Re: SSH Key Files
Posted: Thu Jun 25, 2009 12:51 pm

I'm afraid SP1 doesn't, but it may make it into the next service pack update. The feature was back-burnered for a while there while we focused on some other issues, but it is something I'd like to get in. I'm glad that the update resolved the problem with parsing some of the atypical directory listings that were being returned.

Re: SSH Key Files

Tim Townsend — Thu, 25 Jun 2009 19:06:04 GMT

Author: Tim Townsend
Post subject: Re: SSH Key Files
Posted: Thu Jun 25, 2009 12:06 pm

Mike - Does the sp1 support SSH key files? It is working very nicely for directories now. Tim

Re: AutoRedirect

Mike Stefanik — Thu, 25 Jun 2009 17:47:27 GMT

Author: Mike Stefanik
Post subject: Re: AutoRedirect
Posted: Thu Jun 25, 2009 10:47 am

It doesn't look like you're doing anything wrong. I've been able to reproduce a problem where the control isn't recognizing that the new resource location has been found, so it keeps asking for it again, and eventually gives up because it thinks that it's in a redirection loop (that's why you're seeing the multiple OnRedirect events firing). I'll make sure this is entered into our bug database. For now, the workaround is that if you're getting a redirection status code, look at the value of the Location header field (using the GetHeader method), and that will tell you where you need to go.

Re: GetFile and append

Mike Stefanik — Thu, 25 Jun 2009 17:41:19 GMT

Author: Mike Stefanik
Post subject: Re: GetFile and append
Posted: Thu Jun 25, 2009 10:41 am

You have to specify the byte offset of the resource that you're requesting, and the control will ask for only that range of data, and will write it out to that offset in the local file. It was designed this way to support resuming HTTP file transfers that were canceled, not as a general method to append file data. In other words, it can't be used to append the complete contents of a resource to an existing file; if the byte offset is 0 (the default), the control will always overwrite the file. If what you want to do is retrieve a resource and append it to an existing file, your can use the GetData method to retrieve the data into a string or byte array, and then write it to the end of the file.

Just for general information, even when specifying a byte offset, the other caveat is that the server needs to support the range request for the resource. Not all of them do, and for those that do, it may not be for all types of content. For example, the server may support content ranges for static files, but not for dynamically created content such as PHP pages or pages that use server-side includes.

AutoRedirect

Dave Howard — Thu, 25 Jun 2009 01:01:04 GMT

Author: Dave Howard
Post subject: AutoRedirect
Posted: Wed Jun 24, 2009 6:01 pm

Socket Tools version 6 secure visual edition, HyperText Transfer Protocol Control. I cannot seem to get the AutoRedirect to work no matter what. I have tried setting both the .AutoRedirect option to true and the .Options setting to 4. I have tried hitting both google.com (which redirects to http://www.google.com) and yahoo.com (redirects to http://www.yahoo.com). I can place a messagebox in the OnRedirect event and I can see that the Resource value is being properly set to the redirect resource but the control always returns a 301.

If .AutoRedirect is set false, the control returns 301 and the OnRedirect event fires once. When I set .AutoRedirect to true, the control still returns 301 but the OnRedirect event fires 3 times.

Any clue what Im doing wrong here?

Thanks,

Dave.

GetFile and append

Dave Howard — Thu, 25 Jun 2009 00:52:28 GMT

Author: Dave Howard
Post subject: GetFile and append
Posted: Wed Jun 24, 2009 5:52 pm

Socket Tools version 6, secure visual edition, HyperText Transfer Protocol Control. The GETFILE method implies that I can append to a file:

LocalFile
A string that specifies the file on the local system that will be created, overwritten or appended to. The file pathing and name conventions must be that of the local host.

However, I cant seem to find a way to do it. Any clues on how I can do this and can it be added if it currently isnt supported? Every option seems to overwrite the file.

Thanks,

Dave.

Re: Listener refuses connection most of the time

Mike Stefanik — Wed, 24 Jun 2009 20:25:21 GMT

Author: Mike Stefanik
Post subject: Re: Listener refuses connection most of the time
Posted: Wed Jun 24, 2009 1:25 pm

Are you calling the Accept method once per event trigger? What may be happening is that the queued events aren't getting processed quickly enough because the event notification messages are being routed through the Windows message queue. One thought would be to handle it kind of like how you would an OnRead event: in the OnAccept event handler, repeatedly call the Accept method and spin up new threads as long as it's successful; when an error occurs indicating that there's no more client sessions to accept, then exit the handler and wait for OnAccept to fire again.

Re: Listener refuses connection most of the time

David Rettger — Wed, 24 Jun 2009 17:41:59 GMT

Author: David Rettger
Post subject: Re: Listener refuses connection most of the time
Posted: Wed Jun 24, 2009 10:41 am

I have experienced the same issue that Fiefie noted. I am using SocketWrench.Net that was included in the latest version of Secure Socket Tools .Net. which I obtained a week or so ago. I have an application that runs 24x7, listening for connections. Right now there are about 100 users connected. If I kill the connections, all those users automatically attempt to log in within seconds. The application began life as your sample Server program and was modified from there. The On_Accept function does nothing but launch a new session thread class and pass the socket Handle through to it.

I modified the program to contain a text field where I can set the Backlog value. If I set it to 1, I see connections start up in fairly rapid succession. If I set it to 5, 100 or 200, one or two connections will start and then nothing else will happen. To accept any more, I have to toggle Pause/Listen, basically restarting the listen function. A couple more will start and then no more will come in. At that point, if I set the backlog back to 1 and toggle pause/listen, all the connections will come pouring in again. This can be reproduced 100% of the time.

Any thoughts?

Socket Version: 6.0.60.1058

Re: Listener refuses connection most of the time

Mike Stefanik — Wed, 24 Jun 2009 16:30:35 GMT

Author: Mike Stefanik
Post subject: Re: Listener refuses connection most of the time
Posted: Wed Jun 24, 2009 9:30 am

That's the default value, but it can be set higher on different platforms (various versions of Windows support different maximum backlogs). It doesn't hurt anything if you set it to a value higher than the system supports, it should just use whatever maximum value it allows.

Re: Listener refuses connection most of the time

Fiefie Niles — Tue, 23 Jun 2009 21:16:35 GMT

Author: Fiefie Niles
Post subject: Re: Listener refuses connection most of the time
Posted: Tue Jun 23, 2009 2:16 pm

Yes, we are using multi threaded, each client is each own thread.
The server machine is a Win 2000 SP4 machine.
So I can set sockServer.Backlog to be up to 200 ?
On the documentation it says the default of sockServer.Backlog is 5. Is that for a non server machine ?

Re: Listener refuses connection most of the time

Mike Stefanik — Tue, 23 Jun 2009 21:13:06 GMT

Author: Mike Stefanik
Post subject: Re: Listener refuses connection most of the time
Posted: Tue Jun 23, 2009 2:13 pm

If you're getting "connection refused" errors with an active, running service it actually means that your server is not accepting the client connections fast enough, and there's no more space in the backlog queue to "park" the inbound connection until you do accept. Increasing the backlog should help the situation, not make it worse. The maximum backlog value depends on the Windows platform, but on servers it can have a value as high as 200.

If you're getting a high volume of connections, the most important thing is that you need to accept them as quickly as possible. If you're using a multi-threaded design (which you should be), you should immediately spin up a new thread and start it executing as soon as the connection attempt is made. Having the server block and do some other processing while there are inbound connections will effectively force them to be backlogged, and you can run into this error if the backlog queue of pending connections isn't cleared quickly enough by your service.

Re: Socketwrench Error

Ewan Crawford — Sat, 20 Jun 2009 15:37:25 GMT

Author: Ewan Crawford
Post subject: Re: Socketwrench Error
Posted: Sat Jun 20, 2009 8:37 am

More on this...

I have been able to prove without doubt that if we send a UDP packet on port 4005 via one ethernet interface, and we send at the exact same time a TCP packet on a separate ethernet interface on port 1066 as a broadcast on the InternetServer instance - all of the UDP sockets on the usercontrol are detroyed.

Listener refuses connection most of the time

Fiefie Niles — Fri, 19 Jun 2009 20:05:02 GMT

Author: Fiefie Niles
Post subject: Listener refuses connection most of the time
Posted: Fri Jun 19, 2009 1:05 pm

We are using VB.NET 2008 and SocketWrench .NET edition version 5.0.0.5020.
We have an application that gets a lot of request for connections at the same time, then it sends a string to the client, then it disconnects the client.
Clients requests to connect to this application fail more often than it succeeds (the client socket connection attempt yields a socket error 10061 – Connection Refused).
I set the BackLog property of the listener to 3.
How can I fix this problem ?
Shall I set the Backlog property to anything other than 3 ? (using the default 5 was worse).

The machine is a Win 2000 SP4 machine.
We have the same application that runs on the same machine on a different port, and since hardly anybody connects to that one, we can always connect to that one, and never gets the "connection refused" rejection.
Thank you.

sockServer.Backlog = 3
If Not sockServer.Listen(strLocalAddress, nLocalPort) Then
End If