4 ms·

It wouldn’t help the kernel case here, but I’ve long thought that the socket TCP and UDP APIs were bad in the general use case. Having to build and shuffle aro

It wouldn’t help the kernel case here, but I’ve long thought that the socket TCP and UDP APIs were bad in the general use case. Having to build and shuffle around the sockaddr structure is too low level for the majority use case. I think most programmers would prefer something like: int inet_connect(AF_TYPE, destination, port, options, &error); Also: int inet_listen(AF_TYPE, port, options, &error); So for example: int sock; inet_err err = NULL; sock = inet_connect(SOCK_STREAM, “google.com”, 443, NULL, &err); if ( sock < 0 ) { printf(“Failed to connect: %s\n”, err->message); return -1; } Basically one level more abstraction in the API. The old API could stick around for people who are doing something weird, but this would cover most use cases I think. Added bonus: programs using this API are trivial to add support for IPv6, it is just a recompile.

asveikau 2y ago
> sock = inet_connect(SOCK_STREAM, “google.com”, 443, NULL, &err); You just added a DNS lookup to connect(2). Also, you linked socket creation to all of this. This would make it hard to do an asynchronous version. Today you can create a socket and do a non-blocking connect(2) (after doing your asynchronous DNS lookup) Lastly, I think if you tasked someone with creating that API, they would probably use the old APIs to build it ...
- ape4 2y ago
  That second parameter could accept a text IP-address eg "192.168.100.100". Like the address bar of a browser.
  - braiamp 2y ago
    So, the dns lookup is still there, it's just optional. You would have to pass a flag to tell it not to try to do the lookup or you would have to do something fancy trying to know if the passed parameter is an IP.
  - asveikau 2y ago
    This is already how all the DNS lookup APIs work.
    - tptacek 2y ago
      The problem is with asking the kernel to perform dns lookups.
      - GauntletWizard 2y ago
        If SystemD had it's way, it would. The local system resolver cache is the default on most systems. DNS is well understood. Why not put it in the Kernel? If you're doing that, though, you'd better dang well give me secure key storage in the Kernel, too, or full TLS capability. Allow my program to n load it's RSA/ECC key at startup, then drop privileges to access that file, and have a kernel module handle the cryptography.
        tptacek 2y ago
        It extremely doesn't make sense to have a DNS resolver resident in the kernel: DNS resolution is policy-intensive, involves various upgrades to cryptographic transports, and often requires debugging, all weak points of the kernel. Against all that, there's no performance advantage, and doing it admits a new networking API that almost no applications will use --- most new code being written in higher-level languages that already abstract over system calls.
        GauntletWizard 2y ago
        There's a huge performance advantage, if you ask SystemD - Multiple resolutions can be cached. This is incredible bullshit, of course, but that is one of many lies Pottering has gotten away with.
        toast0 2y ago
        Caching resolutions can be a nice thing, and having in one place can be useful so that the throwing away the cache can be done consistently for all apps when useful (you likely should clear the cache when switching networks, or when the user asks you to), but none of that means it should be a kernel service. If there's enough volume of requests that a kernel level cache meaningfully improves real world scenarios, something is broken in those scenarios. :p (but I think you agree with me)
- jandrese 2y ago
  How often do you not want to support host lookup when doing a TCP or UDP connection? Certainly you could implement these functions using the existing BSD socket libraries, but that misses out on having them used everywhere so you get "free" IPv6 transitions and whatnot.
Cloudef 2y ago
I think plan9 API is the sanest one https://9fans.github.io/plan9port/man/man3/dial.html https://9fans.github.io/plan9port/man/man3/dial.html
jeroenhd 2y ago
The socket API was designed to be a low-level API. If you're writing applications, you probably want to use libcurl/WinInet or some other abstraction over all of the low-level stuff. Using raw connect() calls is like writing your own XML parser when myriad of existing solutions are free and ready to use. Your example would fit perfectly in a libinet library, but I doubt the C standard library is going to include improvements upon this. If you want good internet support, pick a library or, better yet, another language because plain C is terrible for managing arbitrary network inputs anyway. There is also some stuff your code doesn't handle (do you retry when a connection fails but an SRV record lists multiple options? who is supposed to free the inet_err struct, because your example leaks memory? how do you handle attempts to connect over IPv6 on hosts still stuck on IPv4 only?) that I would expect a low-level C interface to be more explicit about.
viraptor 2y ago
There's lots of higher level libraries that can do this nicely. But there has to exist the low level socket API which actually allows all the weird options to exist. Like protocols without ports.

asveikau 2y ago

> sock = inet_connect(SOCK_STREAM, “google.com”, 443, NULL, &err); You just added a DNS lookup to connect(2). Also, you linked socket creation to all of this. This would make it hard to do an asynchronous version. Today you can create a socket and do a non-blocking connect(2) (after doing your asynchronous DNS lookup) Lastly, I think if you tasked someone with creating that API, they would probably use the old APIs to build it ...

ape4 2y ago
That second parameter could accept a text IP-address eg "192.168.100.100". Like the address bar of a browser.
- braiamp 2y ago
  So, the dns lookup is still there, it's just optional. You would have to pass a flag to tell it not to try to do the lookup or you would have to do something fancy trying to know if the passed parameter is an IP.
- asveikau 2y ago
  This is already how all the DNS lookup APIs work.
  - tptacek 2y ago
    The problem is with asking the kernel to perform dns lookups.
    - GauntletWizard 2y ago
      If SystemD had it's way, it would. The local system resolver cache is the default on most systems. DNS is well understood. Why not put it in the Kernel? If you're doing that, though, you'd better dang well give me secure key storage in the Kernel, too, or full TLS capability. Allow my program to n load it's RSA/ECC key at startup, then drop privileges to access that file, and have a kernel module handle the cryptography.
      - tptacek 2y ago
        It extremely doesn't make sense to have a DNS resolver resident in the kernel: DNS resolution is policy-intensive, involves various upgrades to cryptographic transports, and often requires debugging, all weak points of the kernel. Against all that, there's no performance advantage, and doing it admits a new networking API that almost no applications will use --- most new code being written in higher-level languages that already abstract over system calls.
        GauntletWizard 2y ago
        There's a huge performance advantage, if you ask SystemD - Multiple resolutions can be cached. This is incredible bullshit, of course, but that is one of many lies Pottering has gotten away with.
        toast0 2y ago
        Caching resolutions can be a nice thing, and having in one place can be useful so that the throwing away the cache can be done consistently for all apps when useful (you likely should clear the cache when switching networks, or when the user asks you to), but none of that means it should be a kernel service. If there's enough volume of requests that a kernel level cache meaningfully improves real world scenarios, something is broken in those scenarios. :p (but I think you agree with me)
jandrese 2y ago
How often do you not want to support host lookup when doing a TCP or UDP connection? Certainly you could implement these functions using the existing BSD socket libraries, but that misses out on having them used everywhere so you get "free" IPv6 transitions and whatnot.

Cloudef 2y ago

I think plan9 API is the sanest one https://9fans.github.io/plan9port/man/man3/dial.html https://9fans.github.io/plan9port/man/man3/dial.html

jeroenhd 2y ago

The socket API was designed to be a low-level API. If you're writing applications, you probably want to use libcurl/WinInet or some other abstraction over all of the low-level stuff. Using raw connect() calls is like writing your own XML parser when myriad of existing solutions are free and ready to use. Your example would fit perfectly in a libinet library, but I doubt the C standard library is going to include improvements upon this. If you want good internet support, pick a library or, better yet, another language because plain C is terrible for managing arbitrary network inputs anyway. There is also some stuff your code doesn't handle (do you retry when a connection fails but an SRV record lists multiple options? who is supposed to free the inet_err struct, because your example leaks memory? how do you handle attempts to connect over IPv6 on hosts still stuck on IPv4 only?) that I would expect a low-level C interface to be more explicit about.

viraptor 2y ago

There's lots of higher level libraries that can do this nicely. But there has to exist the low level socket API which actually allows all the weird options to exist. Like protocols without ports.