TCPSocket.Listen and Ports

Using a VB.NET app I wrote, I can use a TCPListener to connect to another networked app, and upon connection, I receive a new port, as expected. The communication works from there.

In Xojo, using TCPSocket.Listen, I can connect to the networked app, but the port I get back is the same port I was listening on. (50000)
When using TCPSocket.Connect instead of TCPSocket.Listen in this same app, and connecting to a hardware device (instead of a networked app), the port always comes back after connecting with a new port #, not 50000 and all is well.

For some reason, when using TCPSocket.Listen, the port it comes back with is always the same port I’m using to listen. Same issue on both Mac and Windows.

Anyone ever run into this issue before?

If you want to accept multiple connections on a single port use a ServerSocket instead of a TCPSocket.

Use the ServerSocket class. The ServerSocket listens on the “main” local port and hands inbound connections to instances of TCPSocket using an ephemeral local port. You create the TCPSocket (or a custom subclass of TCPSocket) in a disconnected state in the ServerSocket.AddSocket event.

Not using multiple connections. Just one connection. The issue is that when using TCPSocket.Listen, when the app connects, the port it comes back with is the same port I’m listening on. It SHOULD be a different port. At least that’s the way it works with TCPSocket.Connect.

Is it normal for TCPSocket.Listen to come back with the same port after connecting? My guess would be no…

I looked at the docs for ServerSocket, and tried the example project. I still only get one connection, and it still comes up with the same socket I’m listening on.

Would you be able to show me some example code? The docs and the example projects aren’t working for me.

This is the expected behavior. A TCP connection requires two port numbers: one local and one remote. When you Listen() you specify the local port to await connections on; when you Connect() you specify the remote port that is awaiting your connection.

Consequently, the meaning of the TCPSocket.Port property varies according to whether you’re listening or connecting, and also at what stage in the connection process you’re in.

Before calling TCPSocket.Listen, the TCPSocket.Port value is interpreted as the local port number to use. This value doesn’t change after the connection is established.

Before calling TCPSocket.Connect, the TCPSocket.Port value is interpreted as the remote port number to use. This value will change after the connection is established to reflect the random local port that is used for the connection.

[quote=473815:@Andrew Lambert]Before calling TCPSocket.Listen, the TCPSocket.Port value is interpreted as the local port number to use. This value doesn’t change after the connection is established.[/quote]I don’t follow. Should I be calling Connect a 2nd time after the connection happens on it’s own from a TCPSocket.Listen call? Or are you saying that it doesn’t matter that the port # doesn’t change? Or does it change sometime later? I’m quite confused.

[quote]Before calling TCPSocket.Connect, the TCPSocket.Port value is interpreted as the remote port number to use. This value will change after the connection is established to reflect the random local port that is used for the connection.[/quote]But not when using TCPSocket.Listen?

TCPSocket.Listen doesn’t connect to anything. It just starts listening for remote apps trying to connect to you. TCPSocket.Connect makes a connection to a remote app and returns the port that was negotiated during the connection. I think you may have the two confused.

as i understood from manual you get a AddSocket Event at your server.
this is your new socket there

Var ret As TCPSocket = New ClientSocket(ListBox1, curSocket) curSocket = curSocket + 1 Return ret
ClientSocket seems to be s subclass from TCPSocket

if you return nil i guess this is blocking a connection.
i think AddSocket is a wrong name, should be ConnectionRequest

to make it easy to start
-------------------------------- Server Part
add a server socket to a window and set it via button to listen at a free port as example port 81
in the same window you drop a tcp socket.

button action to set server in listening mode

System.DebugLog("Listen") ServerSocket1.Listen
return the TCPSocket1 from window

System.DebugLog("AddSocket") Return TCPSocket1

add debug output in Connected and DataAvailable Event from TCPSocket1

[code]Sub Connected() Handles Connected
System.DebugLog(“Connected”)

End Sub
[/code]

Sub DataAvailable() Handles DataAvailable System.DebugLog("DataAvailable") End Sub

-------------------------------- Client Part
add a window with a TCPSocket and a button for doing the connect
use address 127.0.0.1 and port 81 as example

TCPSocket1.Connect

add a button to send data

TCPSocket1.Write "Hello"

open this client window in the app start

Var w As New WindowClient w.Show

[quote=473823:@Andy Broughton]I don’t follow. Should I be calling Connect a 2nd time after the connection happens on it’s own from a TCPSocket.Listen call? Or are you saying that it doesn’t matter that the port # doesn’t change? Or does it change sometime later? I’m quite confused.
[/quote]

I’m saying it doesn’t matter that the port number doesn’t change.

[quote]
But not when using TCPSocket.Listen?[/quote]

Right. Listening and Connecting are fundamentally different modes of operation. When you call Connect() you are initiating an outbound connection to a specific port number on a remote system. The OS will allocate a random local port for the connection, and once the connection is established the TCPSocket.Port property is updated to reflect the local port. When you call Listen() you are awaiting inbound connections on a specific local port, and generally don’t care what the remote port is.

In other words, after the socket is successfully connected, whether it’s the listener or the connector, the Port property will reflect the local port being used.

That’s why we’ve talked about the ServerSocket class. Its the only way to have a listener change its local port after connection. Though I’m not sure that’s actually what you’re asking for. Is there a particular reason you’re interested in having the port number change?

if you return the TCPSocket object in AddSocket event the connection is established.

My understanding is that the connection happens when the remote app tries to connect, automatically, and that TCPSocket.Connect does not need to be called. At least that’s the way it reads in the LG:

[quote]Listening for a Connection from Another Computer
Your app can also listen for a connection request from another application. To do this, you use the Listen method:

TCPConnection.Listen
Once you put a socket into listen mode, it waits asynchronously for a connection request. Your app remains responsive while the socket is waiting and code continues to run.

When a connection is requested, the Connected event handler is called, which lets you know you have a connection.[/quote]

So, in the TCPSocket.Connected event, the port # should change to the new randomly selected port, just like it does if I manually connected via TCPSocket.Connect, correct?
If so, then that’s what I’m saying. The port is NOT changing after the connection.

[quote]That’s why we’ve talked about the ServerSocket class. Its the only way to have a listener change its local port after connection. Though I’m not sure that’s actually what you’re asking for. Is there a particular reason you’re interested in having the port number change?[/quote]No, I don’t care if it changes, but it’s not connecting and that’s the only thing I have to go on ATM. I know when it successfully connects using TCPSocket.Connect, the port DOES change.

Thank you, @Markus Rauch .

[quote=473831:@Markus Rauch]
return the TCPSocket1 from window

System.DebugLog("AddSocket") Return TCPSocket1[/quote]

Where does this code go?

in the AddSocket Event from ServerSocket1

xojo 2019r3.1 at google drive
TestServerClient.xojo_binary_project

Ok. Same issue. Getting the same port number as I’m listening on when connected. Not sure if that’s the reason the communication doesn’t happen, but that’s all I’ve got to go on.

Not sure if anyone here understands VB.NET? I’ve made a small app that works and maybe someone can help me figure out how to translate this to do the same in Xojo?

[quote=473802:@Andy Broughton]Using a VB.NET app I wrote, I can use a TCPListener to connect to another networked app, and upon connection, I receive a new port, as expected. The communication works from there.

In Xojo, using TCPSocket.Listen, I can connect to the networked app, but the port I get back is the same port I was listening on. (50000)
When using TCPSocket.Connect instead of TCPSocket.Listen in this same app, and connecting to a hardware device (instead of a networked app), the port always comes back after connecting with a new port #, not 50000 and all is well.

For some reason, when using TCPSocket.Listen, the port it comes back with is always the same port I’m using to listen. Same issue on both Mac and Windows.

Anyone ever run into this issue before?[/quote]

When you “Listen” the port will be bound to the given port so it wil remain the same. When you have another socket that connects it’s given a port that is connected to the listening port. Both cannot be the same.

In Xojo when connecting a tcpsocket it gives you the actual port that the system has assigned and connected to the requested port.

[quote=473806:@Andy Broughton]Not using multiple connections. Just one connection. The issue is that when using TCPSocket.Listen, when the app connects, the port it comes back with is the same port I’m listening on. It SHOULD be a different port. At least that’s the way it works with TCPSocket.Connect.

Is it normal for TCPSocket.Listen to come back with the same port after connecting? My guess would be no…[/quote]

The listening socket keeps the same port that’s normal.

Ok, sounds like a Listener works differently in Xojo from what I would expect. I’m still no closer to getting it to work, unfortunately!

I can post the relevant VB.NET code here if someone feels like they might be able to help me translate?