Solved How to get a socketID (data type long) from an Ip address & Port number

[nector]

Sorry people for asking probably a silly question but it matters most.

How do we get the socketID from an Ip address & Port number using VBA

Example

IP address = "127.0.0.1"
Port number = 7070

Just in case some may not understand the properties above when added together must give us the socketID, but how do we do it so that it ties up with the long datatype

Public Declare PtrSafe Function closesocket Lib "wsock32.dll" (ByVal s As LongPtr) As Long

'Close the socket and transport
Function ClosingNetwork(ByVal Socket As LongPtr) As Long
Call closesocket(Socket)
Call WSACleanup
MsgBox "Port has now closed", vbCritical, "Please Move On"
End Function

 

[cheekybuddha]

How are you creating the socket?

 

[nectorch]

' Create a new socket
    Dim lsocketID As Long
    lsocketID = Socket(AF_INET, SOCK_STREAM, 0)
      
    If lsocketID = SOCKET_ERROR Then
        Err.Raise GENERAL_ERROR, "WinsockOpenTheSocket", "Unable to create the socket!"
    End If
    MsgBox "Here is a SocketID" & " = " & lsocketID

That is the function.

 

[The_Doc_Man]

Normally, you use an API call to create a socket by supplying address family, desired socket type, and protocol family. You either get back a failure code or a data structure that contains the information you wanted.

socket function (winsock2.h) - Win32 apps

The socket function creates a socket that is bound to a specific transport service provider.

learn.microsoft.com

Redirecting

Knowing the IP address is great, but at the same time useless, since the IP doesn't enter into using the socket directly. (I.e. your socket creator call looks up the local IP but after that, Winsock or variants use the socket data structure that contains everything needed. And the port number is a return value for the socket creation code because - particularly if you are dealing with TCP protocol family - the port number is negotiated and won't necessarily be the same number the next time you create a socket a few days later.

If you DIDN'T create the socket (because some other software created it for you) then you should be able to get the socket number from the software that created it in the first place.

 

[cheekybuddha]

That is the function.

So you need to store the lsocketID, no?

 

[nectorch]

So you need to store the lsocketID, no?

Sorry I'm a bit behind what exactly are you saying?

 

[nector]

Are saying I should store the created sockedID and use it in the next stage, meaning this storage should be on an unbound control because each time I login I see new socketID , example 1800, 2792 2074 etc

 

[cheekybuddha]

I'm only guessing, but each socket you create you get its socketID.

Use this same socketID to close it when you need to. You may need to store it in a public variable that is available when you want to close the socket (or put it in a textbox, or write to a table ...)

 

[nector]

Okay Cheeky

You have clear point here of storing the SocketID, the issue is how to get it from module to the form where the users need it . For example see the screen shoot I'm able to see the .created ID

 

[cheekybuddha]

Will you have more than one socket open at once?

 

[cheekybuddha]

the issue is how to get it from module to the form where the users need it

Create a textbox on your form (it can be hidden) to store the socketID, eg txtSocketID.

Then populate it with the lsocketID instead of doing the MsgBox.

Then use the value in txtSocketID when you want to close the socket and clear the textbox.

 

[nector]

Hi Cheekbuddha

Many thanks for your help I'm able to store the socketID in a text box and hide and use it wherever required .

Regards
Chris

 

[The_Doc_Man]

Are saying I should store the created sockedID and use it in the next stage, meaning this storage should be on an unbound control because each time I login I see new socketID , example 1800, 2792 2074 etc

You have an answer for the main question, but I'll answer this one in passing.

Sockets are short-lived entities that last no longer than the duration of a logged-in session. They are TEMPORARY connections to a session, and of course a SESSION is itself a temporary entity used for accounting purposes. Each login will probably get a different port number if your environment uses DHCP network management and TCP (connection-oriented) network pathing because those two network protocols involve dynamic port assignment and dynamic network connections.

It should also be noted that a socket is NORMALLY a private session resource that, unless you do some gyrations, cannot be shared with other sessions. This has to do with where in virtual memory that temporary socket structure is located. Among other things, there are device flags in the device driver structures that related to SHARED or NOT SHARED devices. I could be wrong, but I thought that sockets were NOT SHARED unless you driver-diddled. Therefore, if you want the user to know something about the socket, I would have to ask "Why?" - because if the socket wasn't created IN THEIR SESSION it is pretty much useless to them unless you are doing network troubleshooting. And if it WAS created in their session, the data structure is available locally for their use anyway.

Finally, if you want to do some more reading, an excellent starting point is the "Similar Threads" section below the most recent post in each thread. When the discussion includes good keywords, the Xenforo forum software makes some decent guesses regarding relevant threads.

 

[cheekybuddha]

Finally, if you want to do some more reading, an excellent starting point is the "Similar Threads"

Haha! 4 of the 5 similar threads listed for me below are started by the OP! (nector/nectorch)

 

[The_Doc_Man]

Haha! 4 of the 5 similar threads listed for me below are started by the OP! (nector/nectorch)

Which of course is specific information based on his questions. But a forum search on sockets would also help.

 

[cheekybuddha]

Apologies, Doc, wasn't trying to pour cold water on your (very good) suggestion, was just laughing at the irony in this specific instance!

 

[nector]

Sockets are short-lived entities that last no longer than the duration of a logged-in session. They are TEMPORARY connections to a session, and of course a SESSION is itself a temporary entity used for accounting purposes.

The Doc _ Man is 100% right I was able to see that from the string once I logged out completely the next session I will get a different socketid this has led me to separate the library into a module and functions into a user form, that helped me to grab the actual socketID whether changed or not.

Many thanks to quality IT professionals for correcting me on this.

Regards

Ch