getnameinfo and tcp connection

[koce]

I tried reworking the getaddrinfo() / getnameinfo() example from the man page, https://linux.die.net/man/3/getaddrinfo , which is built over datagram socket. My idea was to test these functions over stream socket, so I added listen() and accept() calls to establish the tcp. Client and server did talk to one another, but the getnameinfo() call failed to provide actual host/ service with error code :

-6 ( EAI_FAMILY The address family was not recognized, or the address length was invalid for the specified family. )

In my server code, https://gist.github.com/Koceto1973/ef77dcdda949d0fb817560e1a0bae10e , recvfrom() call ( line 97 ) fails to provide correct peer_addr and peer_addr_len is zeroed, guess that's what ruins the getnameinfo().

Would appreciate some hints, thanks.

[koce]

My doubts got confirmed - it is the recvfrom() call that did not work as I expect,

removed recvfrom() and sendto(), used only recv() and send() for my tcp socket,
then used getpeername() to load the sockaddr structure and get the host / service.

Tested again getnameinfo() after that and it worked fine - getpeername() has taken proper care of it's input.

The only question remaining:
Is recvfrom() not supposed to load sockaddr struct correctly if used ( although not required ) with tcp socket? Or my implementation has issues ... ?

[kbw]

The sockets library is object oriented. However, it's written in C, so there's no compile-time enforcement of the interface. You have to do the right thing, and check return codes for errors. This is an example where C++ is faster because the checks can be done at compile time.

Think of sockaddr as a base class. sockaddr_in is a derived class for IPv4, sockaddr_in6 for IPv6 and so on. That's address type. All the calls specify sockaddr*, but it's really just an abstract base, that's why you have to cast your actual address type on use.

There's also protocol. In networking, we use datagrams, but we can use those to create streams. In IPv4, datagrams are available in protocol IPPROTO_UDP, you can send to and receive from anyone, the corresponding calls are sendto and recvfrom. The equivalent stream, IPPROTO_TCP, works on connected enpoints, so send and recv are sufficient, but you are required to connect or accept first. Any endpoint that's going to be connected to must first bind to known address, so it can be found.

BSD sockets also supports Novell's IPX/SPX, ... the system is open, you can plug in your own. It's pretty cool, once you get your head around it.

Some Winsock extension are not cool, like AcceptEx in the previous thread, the lovers of opaque abstractions getting it wrong again while trying to claw back performance from a clumsy design.

Wanna see how asio can be used with sockets? See BSD kqueue with asio on file descriptors. No crazy extensions to any of the subsystems.

[koce]

Thank you.

It's clear there're lot's of advanced stuff to explore, once the need/ interest comes to mind.
I'm exploring the libuv library also and realized some proper basics has to be covered first.