TCPSocket.Listen and Ports

  1. ‹ Older
  2. 3 weeks ago

    Derk J

    Feb 4 Pre-Release Testers, Xojo Pro
    Edited 3 weeks ago

    @Andy B Thank you @Andrew L !!

    So... In the end, nothing to do with Listen or Sockets. It threw me off at first that the returned port was the same as the listen port, because I foolishly thought that the Automatic connect and the Connect method would function the same, and that the random port would be returned upon connect. Kinda weird, but so's a lot of stuff with Xojo, but anyway, barking up the wrong tree.

    Came down to the Handshaking message in the Timer. This is what I had:

    Dim HandShake As String = Chr(&hF0) + Chr(&h43) + Chr(&h10) + Chr(&h3E) + Chr(&h19) + Chr(&h7F) + Chr(&hF7)
    TCPSocket1.Write(HandShake)

    This is what Andrew suggested:

    Dim HandShake As MemoryBlock = DecodeHex("F043103E197FF7")
    TCPSocket1.Write(HandShake)

    Andrew's works, mine doesn't. No idea why. TCPSocket.Write should be able to take a string just as easily as a MemoryBlock, but maybe not?

    Bottom line is that TCPSocket.Listen doesn't work as I would have expected, but neither does TCPSocket.Write.

    Thanks everyone!

    It didn't work because you should have used ChrB() instead of Chr() you want the byte values to be sent.
    The version of @Andrew L is much more readable.

    Glad it worked out.;)

  3. Andy B

    Feb 4 Airdrie, AB, Canada

    @Maurizio R I think you need some background on TCP/IP networking: there are many books on this topic.

    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.

    You can also use TcpView to monitor and see what happens when VB.NET application runs.
    Don't guess.

    I'll check out TCPView. Thanks for the tip!

  4. Andy B

    Feb 4 Airdrie, AB, Canada

    @Kevin G Did you try ChrB rather than Chr? My guess is the string you are creating using Chr is not correct because you are using values > 127.
    Debugging the string variable’s binary data would confirm that.

    @Derk J It didn't work because you should have used ChrB() instead of Chr() you want the byte values to be sent.
    The version of @Andrew L is much more readable.

    Glad it worked out.;)

    Thanks! Yeah, my inexperience with Xojo.
    I should really be using MemoryBlock more instead of strings anyway.

  5. Maurizio R

    Feb 4 Pre-Release Testers, Xojo Pro

    @Andy B 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.
    I'll check out TCPView. Thanks for the tip!

    The random port isn't something returned by the framework you are using but is TCP specific and also totally unrelated to the OS you are using.
    No framework can dictate how listen, connect or bind works or can be implemented.
    These and other details are clearly documented in how a TCP connection is made and behave.
    Mastering sockets isn't exactly something that can be done on trial and error basis.

  6. Andy B

    Feb 4 Airdrie, AB, Canada

    @Maurizio R The random port isn't something returned by the framework you are using but is TCP specific and also totally unrelated to the OS you are using.

    Ok, I'm curious... so why then does VB.NET return a random port number, and Xojo return the same port number as the listener? I'm not talking about what's being done "under the hood" but how Xojo differs from VB.NET.
    If this is not of interest to you, no need to reply.

  7. Maurizio R

    Feb 4 Pre-Release Testers, Xojo Pro
    Edited 3 weeks ago

    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.

  8. Andy B

    Feb 4 Airdrie, AB, Canada

    Thanks, @Maurizio R . We're talking about 2 different things. No worries. Appreciate the help.

  9. Maurizio R

    Feb 4 Pre-Release Testers, Xojo Pro
    Edited 3 weeks ago

    Don't worry.
    Xojo's socket works just fine.

    Best regards.

  10. Norman P

    Feb 4 Pre-Release Testers, Xojo Pro in bed sick :(

    @Andy B Thanks, @Maurizio R . We're talking about 2 different things. No worries. Appreciate the help.

    replied on If Not Nil

  11. Maurizio R

    Feb 4 Pre-Release Testers, Xojo Pro

    @Andy B 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.

    He is so confident that this is an issue...

  12. Norman P

    Feb 4 Pre-Release Testers, Xojo Pro in bed sick :(

    @Maurizio R He is so confident that this is an issue...

    snide remarks do not help

  13. Maurizio R

    Feb 4 Pre-Release Testers, Xojo Pro

    @Norman P snide remarks do not help

    I leave this oppotunity to you

  14. Matthew S

    Feb 5 Pre-Release Testers, Xojo Pro
    Edited 3 weeks ago

    @Andy B 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.

    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.

  15. Andy B

    Feb 5 Airdrie, AB, Canada

    Thank you, Matthew. An excellent explanation.

    It's too bad there's no equivalent to the VB.NET .RemoteEndPoint function in Xojo!

  16. Tim H

    Feb 5 Pre-Release Testers Portland, OR USA

    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.

  17. Matthew S

    Feb 8 Pre-Release Testers, Xojo Pro

    @Andy Broughton It's too bad there's no equivalent to the VB.NET .RemoteEndPoint function in Xojo!

    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 Function

    Due 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.

  18. Matthew S

    Feb 8 Pre-Release Testers, Xojo Pro

    @Tim H There are 2 kinds of TCP sockets in Xojo that listen. TCPSocket and ServerSocket.

    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.

    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.

    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.

  19. Maurizio R

    Feb 8 Pre-Release Testers, Xojo Pro

    @Matthew S 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.

  20. 2 weeks ago

    Matthew S

    Feb 10 Pre-Release Testers, Xojo Pro

    @Maurizio R 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.

  21. Maurizio R

    Feb 10 Pre-Release Testers, Xojo Pro

    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.

or Sign Up to reply!