LBNet and UDP

[fwm]

Hello.

I guess this post is aimed mainly at Chris Iverson, who I worked with when he created the original DLL that has become LBNet. I say "worked with", but in actuality I bombarded him with many, many questions and he kept answering them and writing code to make stuff happen. "Can it do TLS?" I asked. "I can make it do TLS" Chris replied. "Can we feed it a certificate and act as a server?" I asked. "I can make it do that, yes" he replied. I already thanked Chris before, but again I must thank you, Chris, for the time and effort you went to in explaining how the DLL worked and helping me understand things that I would never have understood about TCP, TLS, etc.

I have been having a play around with the newer UDP functions. I wonder if there's a way to test if a UDP service is running on a particular port with the DLL. I can test for a TCP connection simply by using the Connect() function, and then the IsSocketInvalid() to check. This is all I need to check if a TCP service is running on a port or not. However the same doesn't seem to work with the UDPConnect() function. It seems that I can insert any port, whether a UDP service (e.g. an NTP server) is running on that port or not, and the connection appears to be successful. Now this may be my limited understanding of the differences between UDP and TCP, but can we use any of these functions to test for a UDP connection? I'm not looking for any particular response other than to establish whether a UDP service is at the other end or not.

I would love to hear from Chris or anyone else who has an understanding of this protocol  - I'm sure there are many with a far better understanding than me!

Thank you

Keith

[Chris Iverson]

There's no real way to check this, because of the differences between the TCP and UDP protocols.

Despite the name, UDPConnect() is really just a shorthand for creating a socket with the target host and port filled in, allowing the use of the simpler send() and recv() functions, instead of needing to use sendto() and recvfrom() each time.

Calling connect() on a UDP socket doesn't actually establish a connection, because there's no connection to establish. It's a connectionless protocol.

With TCP, you don't get a proper socket back until the local computer has actually communicated with the remote computer, and the remote computer has actively accepted the connection. (At the protocol level, this means that both sides have successfully send and received a sync packet and an acknowledgement packet. This is done through a three-packet handshake; the computer making the connection sends a sync packet(SYN), the computer receiving the connection sends back a combined acknowledgement and sync packet(SYN/ACK), and then the computer making the connection replies with its own acknowledgement(ACK).)

Until that SYN-SYN/ACK-ACK handshake is complete, neither side will receive a working socket from the TCP/IP stack, and if something goes wrong with that handshake, they will not get a valid socket back.

This is why you can test using "IsSocketInvalid()" on TCP connections; if it can't establish the TCP connection, you'll get an invalid socket back.


For UDP, because there's no established, concrete "connection", there's no way to tell if the other side is actually listening other than sending data and seeing what happens.

When UDPConnect() sets up a socket, it just creates a socket, points it to the remote computer, and gives it back to you. It's a "valid" socket, and you're perfectly capable of sending data using that socket, but you have no way of knowing for sure whether or not you'll get data back, or even if someone's actually listening, until you actually try to send data.


Essentially, checking if there's actually a listening service at the other end requires actually communicating with that other end. For connection-oriented protocols(i.e. TCP), this is done as part of the protocol, and is handled by the network stack(the TCP SYN-SYN/ACK-ACK handshake mentioned above). For connectionless protocols(i.e. UDP), well, fire away and see what happens.

[fwm]

Thanks for the detailed explanation Chris. I get it from what you've said. Perhaps I need to refine my needs here, I'm trying to check if an NTP server is running or not. NTP answers on port 123 via UDP but I believe it only answers when a it receives a UDP packet containing binary data. Do you think that the UDP functions could be used to check the NTP server's up and running , and if not return an error after a set timeout? I think I see everything that would be needed in the UDP functions, although I'm struggling to get my head around the NTP protocol and the binary data. I don't actually need to use the NTP server's answer to change any times or work out if something is in sync, I am just trying to check if the NTP server is responding or not.

[Chris Iverson]

I imagine they have the NTP server drop any invalid NTP requests, to avoid overloading it, so I think you would need to send a valid NTP packet to the server, and then check to see if you get a response. You don't have to do anything with it, but getting a response would be the important part.

[fwm]

I'll look into how to form a valid NTP packet and see what I can come up with. Thanks Chris.