I think that you can’t explain what is this random port number returned by VB.NET: are you sure it is a TCP port or something else?
Using the netstat command are you able to see what is the TCP port used by your VB.NET application to listen for client connections?
Do you understand what bind means for TCP?
Don’t reply to me, ask and reply to yourself.
Thanks, @Maurizio Rossi . We’re talking about 2 different things. No worries. Appreciate the help.
Don’t worry.
Xojo’s socket works just fine.
Best regards.
replied on If Not Nil
He is so confident that this is an issue…
snide remarks do not help
I leave this oppotunity to you
[quote=474069:@Andy Broughton]No doubt.
However, I’m not sure how that would lead to an understanding of the Xojo syntax and functionality, especially since the VB.NET version returns the random port. My real problem I think is my inexperience with Xojo.[/quote]
Sorry but I am with Maurizio on this. The real problem is not Xojo or vb .net but rather (being cynical) the propensity of software developers to skip the TCP primer and wade into network applications. There are many issues with Xojo’s network classes but this is not one of them.
The Xojo TCP socket class is essentially a wrapper around the Berkeley Sockets API used to build the underlying OS and the functionality is similar. The VB .NET implementation appears to be abstracted a little further (for better or worse) but depends on the very same underlying API.
What you are calling a ‘random port’ is not random at all. Within the UDP and TCP protocols a port address may be ‘reserved,’ it may be ‘well known,’ it may be ‘ephemeral,’ but it must never be ‘random.’
To answer your question, consider the empirical assertion.
All TCP packets destined for a web server application must have 80 in the destination port field, regardless of the originating web browser. All packets sent from a web server must therefore have 80 in the source port field, regardless of the port in the destination field.
From the assertion we may infer. i) There are two sockets involved in a TCP conversation. ii) One socket is bound to your application (local). iii) The other socket is bound to a different application that may be on a different device (remote). iv) One socket’s port address is and must be known before a connection can be established. v) The other socket’s port address may not be known before a connection is established.
When you are looking at a web server process, and see a port address that is a large number, you may deduce that the port address you are looking at is not the local port address, within the ‘well known’ ports range. The large number is probably within the ‘ephemeral’ range and is probably the remote port address of a connected web browser.
Sure enough, when I take a look at your vb .net code, at line #13 I find the local port address is 50000. On line #28 I find the code refers to LANClient.Client.RemoteEndPoint, the remote port address.
The vb .net and Xojo socket interfaces are behaving the same way (because they have to) but you have incorrectly assumed you are looking at the same socket property, which you are not. Xojo’s TCPSocket.Port refers to the local port address; embedded in the source port field of the TCP packet headers your application writes to the wire. The vb .net Client.RemoteEndPoint refers to the remote port address; embedded in the source port field of the TCP packet headers your application reads from the wire.
Thank you, Matthew. An excellent explanation.
It’s too bad there’s no equivalent to the VB.NET .RemoteEndPoint function in Xojo!
There are 2 kinds of TCP sockets in Xojo that listen. TCPSocket and ServerSocket. TCPSocket represents a single, fixed port connection. That port will never change. ServerSocket functions by allocating multiple TCPSockets and holding them in reserve. When an incoming connection happens, it selects a “random” port and hands the connection off to one of the TCPSockets to handle on that port. Then it continues listening for more incoming connections. I suspect the VB.NET socket functions more like the ServerSocket than a TCPSocket.
Here you go.
I wrote code snippet below in Real Basic around 10 years ago but Xojo (2019r2.1) compiles it and it still appears to work.
Structure sockaddr_in
sin_family As Int16
sin_port As UInt16
sin_addr As UInt32
sin_zero As String * 8
End Structure
Public Function RemotePort(Extends s As SocketCore) as integer
//returns the remote port used by a connected socket or -1
#if TargetLinux //Not yet supported
Return -1
#elseif TargetWin32 //target Windows
Declare Function getpeername Lib "ws2_32" (handle as integer, byref name as sockaddr_in, byref sz as integer) As Integer
#else // target OSX
Declare Function getpeername Lib "System" (handle as integer, byref name as sockaddr_in, byref sz as integer) As Integer
#endif
dim ret as integer, sz as integer, h as integer
dim sockAddr as sockaddr_in, mb as MemoryBlock
h = s.handle
sz = sockAddr.Size
ret = getpeername(h, sockAddr, sz)
if ret = 0 then
//correct cross platform endianness
mb = new MemoryBlock(sockAddr.Size)
mb.LittleEndian = true
mb = sockAddr.StringValue(false)
ret = mb.UInt16Value(2)
end if
return ret
End FunctionDue to the proliferation of NAPT (network address translation,) in modern IP networks the remote port address is often a, not very useful number. The remote port address is only reliable on very simple network infrastructures or with processes running on a single host. In many cases the remote port address will be the port number the nearest NAT router used to multiplex the public IP on the outside interface.
There is only one kind of TCP socket in the underlying OS and there is only one kind of TCP socket in Xojo.
ServerSocket descends from Object, whereas sockets descend from SocketCore. The ServerSocket class is not a socket but rather a manager of TCPSockets. In fact, when I subclass ServerSocket I am in the habit of using the name SocketServer to remind myself what the class does - it serves up TCPSocket connection requests.
Calling ServerSocket.Listen fires the ServerSocket.AddSocket event as many times as there will be sockets in the ServerSocket pool. Within the AddSocket event a TCPSocket needs to be instanced and returned. ServerSocket adds the TCPSockets returned from AddSocket to an internal array (that is visible in the debugger). ServerSocket sets the first socket in the pool to the Listen state and from there on it is the TCPSocket instance that fires events. When the first socket receives the first SYN packet the underlying socket is no longer in the Listen state, so SocketServer sets the next TCPSocket in the pool to listen. A technique for mitigating the latency inherent within TCP handshaking that is as old as early web servers.
[quote]TCPSocket represents a single, fixed port connection. That port will never change. ServerSocket functions by allocating multiple TCPSockets and holding them in reserve. When an incoming connection happens, it selects a “random” port and hands the connection off to one of the TCPSockets to handle on that port.[/quote]Once again the need for a TCP primer.
Sorry Tim, it can not work the way you describe because TCP and the Sockets API do not work the way you describe. Frankly, the ServerSocket documentation is shockingly wrong. I last renewed my RealStudio sub in 2012 and come to Xojo 8 years later to find the ServerSocket class remains just as broken as before. Try calling ServerSocket.StopListening - It doesn’t!
I will reiterate that a TCP socket is an operating system resource. Applications do not assign sockets or port numbers, only the OS can do that. Applications request sockets and port numbers. Sockets and socket functionality are mainly the same regardless of the platform or programming language used to call on them. Take a look at the declares in the snippet I posted earlier. The getpeername() function uses the same name and takes the same parameters on Windows as on MacOS.
Thankfully the Xojo TCPSocket is a simple wrapper around the OS functionality and remains reliable because of that. And if you ever tried programming sockets in C, you will know why I sometimes use Xojo instead.
C programming is like Xojo programming: you must know what to do and how to do it.
True to an extent but with Xojo I can put something useful together in an afternoon. Xojo is not a bad tool for network test and investigation. In many cases I find it quicker to write a test harness from scratch in Xojo than work up the equivalient with Netcat.
Xojo, in my opinion, is for fast prototyping and for casual programmers.
Is great for web applications i.e. for applications used from a web browser: you can do things with it in a very short time and if you add some css and javascript skills you can have achieve very professional results.
Each tool has strengths and weaknesses.
Xojo is very strange when compared to other languages: isn’t a language but a programmable framework so is very difficult to compare with a generic language like C.
Your example code posted above is simply a generic C code snippet (reported in many TCP books) adapted to Win32 and translated to Xojo.
In any case: use the best tool you know for the task to accomplish.
Better if you known more than one.
Best regards.