TcpSocket Advice. Socket Reset by Peer.

@Wayne Golding Thanks so much for all your help.

@Wayne Golding I’m having a bit of trouble trying to get the number of ActiveSockets. I wrote my client app to connect and stay connected indefinitely so I could test my code and I’m still getting a -1 from activeconnections.ubound.

It’s a console app so no window properties. I have a ServerSocket called SckListen. Here’s the code I am trying to implement. Can you tell me what I am doing wrong? Thanks.

dim ms() as TCPSocket dim mServerSocket As New SckListen ms()=mServerSocket.ActiveConnections()

I always get -1 from ms.Ubound

Have a look at this project. Addsocket wasn’t the correct place to collect the info you want.

@Wayne Golding Thanks I will.

[quote=256391:@Ryan Haynes]

dim ms() as TCPSocket dim mServerSocket As New SckListen ms()=mServerSocket.ActiveConnections()

I always get -1 from ms.Ubound[/quote]
You should always get -1 from that code. mServerSocket isn’t listening yet, so it can’t have any active connections. Perhaps you should use the actual serversocket that you have in use, instead of creating a new object here.

@Wayne Golding Thanks I knew I had to use App.ServerSocket somehow and the way I was using New wasn’t working but I wasn’t sure how to actually call the ServerSocket to use the reference correctly and your example showed me exactly what I was doing wrong. I have it working now so thank you.

@Tim Hare Hi TIm! Long time since I’ve spoke to you on here. Thank you for the reply you are exactly right I wasn’t using the actual ServerSocket I had in use.

I still don’t understand why when you create a property off the App named the same thing as my ServerSocket it just works together? I have it working, but it would be great to understand the reasoning behind this.

It’s all a matter of scope. When you Dim x As New y x is only available in that method, when you x = New y where x is a property of a class or module it’s scope is much wider and can therefore be referenced from elsewhere. Also when you Dim x … that object/item will “go out of scope” when the method completes which will most likely result in the object being destroyed. I say most likely because you can create references to that object that may have other scopes, for example:

Dim mySocket As New Server Socket App.mySocket = mySocket

@Wayne Golding So it has nothing to do with naming the ServerSocket property of app the same thing as the actual ServerSocket. I could have named them both something unique as long as I create a property and dim the property = new ServerSocket so it has a wider scope. I see now, thanks.

It’s better that they have different names. The compiler chooses the variable with narrower scope, so if you name a local variable the same as a global variable, the local variable “hides” the global one and prevents you from accessing it.