Validating a UDP peer address/port
lazarus / 38-Networking and Web Programming

----------------------------------------------------------------------
colo · 2024-03-09 16:39

I am creating a simple GUI to help users configure a shared library
that will end up communicating over UDP sockets on Windows. The user
is expected to provide the host (IPv4 address, IPv6 address, or DNS
hostname) of the UDP listener/peer, as well as the port number where
the peer is expected to listen at eventually.

Now I would like to avoid in doing any kind of parsing and
verification of the provided host string myself, since the host OS's
network stack can do all the relevant work (and mopre) by itself
anyway. I just don't know how I would best employ that capabilty from
a Lazarus program (that's required to work on Windows exclusively, if
that makes things easier)

Basically, what I want to achieve is to have a procedure that takes
two user inputs (a "host" portion as a string, which can be either a
supported IPv4 (like dotted quad) address notation or IPv6 address
notation or a DNS hostname, and the port number as an integer), then
tries to make the OS open a UDP socket with AF_INET/AF_INET6 family
and SOCK_DGRAM, then call connect() upon it to set its (DNS-resolved,
if need be) peer address, and communicate to the caller (and
eventually also the user) any errors this causes. (Potential errors
could be: The hostname passed in is invalid. The hostname cannot be
resolved. The IP address passed in is invalid. etc.)

No actual data transfer over that socket is planned or even required -
I just want to find out if the data provided "makes sense" in a UDP/IP
context.

What's the path of least resistance to make this happen?

----------------------------------------------------------------------
nouzi · 2024-03-09 17:34

You can uses Regular expression for IP

----------------------------------------------------------------------
Remy Lebeau · 2024-03-09 20:47

Quote from: colo on March 09, 2024, 05:39:50 pmWhat's the path of
least resistance to make this happen?

Use getaddrinfo() and let it do all of the parsing and resolving for
you.  It will parse an IP address string and tell you whether it is
IPv4 or IPv6, and it will resolve a hostname and give you all of the
IPv4 and/or IPv6 addresses that it resolves to.  It can even parse a
port number for you, too.  You will need this parsed/resolved
information when creating the appropriate type of socket and
connecting it.

----------------------------------------------------------------------
colo · 2024-03-10 13:16

@nouzi: Thanks for your suggestion, but for reasons outlined in the
initial post, I do not consider this approach viable or acceptable.


@Remy: Thanks a lot for your input - I am severly hampered in this
endeavor because I have close to 0 familiarity with the Windows API,
and am rather bad at fpc/Lazarus development (but trying to improve! )
as well... It's VERY good to know that getaddrinfo() exists in
Windows, too! The only missing piece of the puzzle for me (I hope!) is
how FPC/RTL/LCL expose getaddrinfo() to my humble programming skills -
if it does at all, because I could not find it in the RTL reference...

Will I have to resort to a third-party library (I discovered lNet and
tried to use it for ther stated purpose, but could not get the error
callback to fire for contrived but obvious errors I provoked, like a
port number > 65535 - and I am not sure what specific
resolution/lookup infrastructure gets used under the hood, i. e. if
getaddrinfo() can be involved, or if it uses some other, older, less
powerful/complete API from Winsock or the like?), or is it more apt to
try to formulate an appropriate Win32 API call to getaddrinfo()
directly?

----------------------------------------------------------------------
Remy Lebeau · 2024-03-11 22:57

Quote from: colo on March 10, 2024, 02:16:42 pmThe only missing piece
of the puzzle for me (I hope!) is how FPC/RTL/LCL expose getaddrinfo()
to my humble programming skills - if it does at all, because I could
not find it in the RTL reference...

According to FreePascal's documentation on it, it is in the libc unit
of the libc package.

----------------------------------------------------------------------
PascalDragon · 2024-03-12 20:51

Quote from: Remy Lebeau on March 11, 2024, 11:57:14 pmQuote from: colo
on March 10, 2024, 02:16:42 pmThe only missing piece of the puzzle for
me (I hope!) is how FPC/RTL/LCL expose getaddrinfo() to my humble
programming skills - if it does at all, because I could not find it in
the RTL reference...

According to FreePascal's documentation on it, it is in the libc unit
of the libc package.

The libc unit is deprecated and only available for i386-linux, do not
use.

The correct unit is cnetdb with Pascal-style wrappers provided in
netdb.