bgnet | Beej 's Guide to Network Programming source | Learning library

I found out the problem...

This is not related to networking at all. Threads are not guaranteed to be started in the same order that you specify, so this is pretty much normal. Please read about threading and if possible about POSIX threads so that you can get a better insight.

sizeof *pfds is the size of the structure, not the size of the pointer. Both of your examples are equivalent. I prefer the first form, since it's easier to maintain - if the type of the structure changes, you only have to fix it in one spot.

sizeof pfds would be the size of the pointer.

The relevant excerpts from the page are

The thing to do is to pack the data into a known format and send that over the wire for decoding. For example, to pack floats, here’s something quick and dirty with plenty of room for improvement

and

On the plus side, it’s small, simple, and fast. On the minus side, it’s not an efficient use of space and the range is severely restricted—try storing a number greater-than 32767 in there and it won’t be very happy! You can also see in the above example that the last couple decimal places are not correctly preserved.

The code is presented only as an example. It is really quick and dirty, because it packs and unpacks the float as a fixed point number with 16 bits for fractions, 15 bits for integer magnitude and one for sign. It is an example and does not attempt to map floats 1:1.

It is in fact rather incredibly stupid algorithm: It can map 1:1 all IEEE 754 float32s within magnitude range ~256...32767 without losing a bit of information, truncate the fractions in floats in range 0...255 to 16 bits, and fail spectacularly for any number >= 32768. And NaNs.

As for the endianness problem: for any protocol that does not work with integers >= 32 bits intrinsically, someone needs to decide how to again serialize these integers into the other format. For example in the Internet at lowest levels data consists of 8-bit octets.

There are 24 obvious ways mapping a 32-bit unsigned integer into 4 octets, of which 2 are now generally used, and some more historically. Of course there are a countably infinite (and exponentially sillier) ways of encoding them...

I've always used gethostbyname() since "forever". It's always worked, it continues to work, and it's "simpler".

getaddrinfo() is the newer function:

http://man7.org/linux/man-pages/man3/getaddrinfo.3.html

The getaddrinfo() function combines the functionality provided by the gethostbyname(3) and getservbyname(3) functions into a single interface, but unlike the latter functions, getaddrinfo() is reentrant and allows programs to eliminate IPv4-versus-IPv6 dependencies.

I understand that getaddrinfo() ismore robust, more efficient, and more secure: You shouldn't be using gethostbyname() anyway

ADDENDUM:

In reply to your specific questions:

A] getaddrinfo() is preferred over gethostbyname() to lookup the IP address of a hostname; either "client" or "server".

B] Q: How would I modify the hints struct and the function parameters?

A: The "hints" look OK, but I would probably modify the port to NULL.

Here's a complete example:

https://www.kutukupret.com/2009/09/28/gethostbyname-vs-getaddrinfo/

"Is it required to place "struct" in front of a struct instance in c++" - In general; No, That's a C'ism. Exceptions do exist though.

The reverse lookup does not use the DNS cache. Instead it uses the rDNS lookup, i.e. the in-addr.arpa pseudo-domain. Well, it turns out that:

The server then responds to that port number. Yes, this is unusual

There is nothing unusual about that. This is how most UDP servers are meant to work. They always respond to the sender's port. They have no concept whether that port is fixed or ephemeral, that is for the sender to decide. Unless a particular protocol dictates that responses are to be sent to a different port, which is not common.

All my searches online point to using bind()

Correct, that is what you need in this situation.

but that code is usually on the server side.

There is nothing preventing a client from using bind().

I haven't found a way to bind on the client side using the modern getaddrinfo() method.

It is the exact same as on the server side, except that you have to bind to a specific IP address, you can't bind to 0.0.0.0 or ::0 like you can with a server socket.

I tried to add a bind() right after the socket() setup but that wouldn't work

Yes, it does. The problem is that you are using the SAME IP address for both binding and sending, and that will not work. You need to bind to the CLIENT's IP address and then send to the SERVER's IP address.

because p is a server-side structure (derived from the hints structure that uses the server IP address)

You are misusing p. You can't bind() a client socket to the server's IP address (you need to use connect() for that instead). You need to bind() a client socket to an IP address that is local to the client's machine. Just like you have to bind() a server socket to an IP address that is local to the server machine.

Remember, a socket is associated with a pair of IP addresses. bind() establishes the socket's LOCAL IP address. connect() establishes the socket's REMOTE IP address.

I want to do this in a way that will work for both IPv4 and IPv6.

You can't create a single client socket for both protocols. You need separate sockets for each protocol (on the server side, you can create a single socket for both protocols, if your platform supports dual-stack sockets).

I've seen other examples whereby a local/source sockaddr_in structure is filled out with the client's information and that is used in the bind, but those are IPv4 or IPv6 specific.

Yes, because you will be sending a packet using EITHER IPv4 OR IPv6, you can't send a packet using both protocols at the same time (a dual-stack socket can receive packets from either protocol, though).

Can someone please show me how to properly update the talker.c code to sendto() and recvfrom() a UDP server using a fixed source port number . Assume that the server is immutable

Try something like this:

If the peer of a TCP connection closes the connection, it will lead to a recv call on your end to return 0. That's the way to detect closed (but not broken) connections.

If you don't currently receive anything from the peer, you need to make up a protocol on top of TCP which includes receiving data.

Furthermore, sending might not detect broken connections (like missing cables etc.) directly, as there are a lot of retransmissions and timeouts. The best way is again to implement some kind of protocol overlaying TCP, one that for example contains a kind of "are you there" message which expects a reply. If a reply to the "are you there" message isn't received within some specific timeout, then consider the connection broken and disconnect.