4 ms·

I've always thought a problem with Nagel's algorithm is, that the socket API does not (really) have a function to flush the buffers and send everything out inst

• lysace 9mo ago
  Something like sync(2)/syncfs(2) for filesystems. Seems like there's been a disconnect between users and kernel developers here?
• loeg 9mo ago
  TCP_CORK?
  • x2rj 9mo ago
    Sadly linux only (and apparently some BSDs). Would love to have more (and more generalized) tcp socket modes like that.
• derriz 9mo ago
  Yeah, I’ve always felt that the stream API is a leaky abstraction for providing access to networking. I understand the attraction of making network I/O look like local file access given the philosophy of UNIX. The API should have been message oriented from the start. This would avoid having the network stack try to compensate for the behavior of the application layer. Then Nagel’s or something like it would just be a library available for applications that might need it. The stream API is as annoying on the receiving end especially when wrapping (like TLS) is involved. Basically you have to code your layers as if the underlying network is handing you a byte at a time - and the application has to try to figure out where the message boundaries are - adding a great deal of complexity.
  • calineczka 9mo ago
    > message oriented Very well said. I think there is enormous complexity in many layers because we don't have that building block easily available.
    • mort96 9mo ago
      It's the main reason why I use websockets for a whole lot of things. I don't wanna build my own message chunking layer on top of TCP every time.
      • mgaunard 9mo ago
        WebSocket is full of web-tech silliness; you'd be better off doing your own framing.
        • mort96 9mo ago
          Well, it also has the advantage of providing pretty decent encryption for free through WSS. But yeah, where that's unnecessary, it's probably just as easy to have a 4-byte length prefix, since TCP handles the checksum and retransmit and everything for you.
          • mgaunard 9mo ago
            It's just a standard TLS layer, works with any TCP protocol, nothing WebSocket-specific in it. You should ideally design your messages to fit within a single Ethernet packet, so 2 bytes is more than enough for the size. Though I have sadly seen an increasing amount of developers send arbitrarily large network messages and not care about proper design.
            • mort96 9mo ago
              Meh I've worked enough with OpenSSL's API to know that I never ever want to implement SSL over TCP myself. Better let the WebSocket library take care of it.
• amluto 9mo ago
  The socket API is all kinds of bad. The way streams should work is that, when sending data, you set a bit indicating whether it’s okay to buffer the data locally before sending. So a large send could be done as a series of okay-to-buffer writes and then a flush-immediately write. TCP_CORK is a rather kludgey alternative. The same issue exists with file IO. Writing via an in-process buffer (default behavior or stdio and quite a few programming languages) is not interchangeable with unbuffered writes — with a buffer, it’s okay to do many small writes, but you cannot assume that the data will ever actually be written until you flush. I’m a bit disappointed that Zig’s fancy new IO system pretends that buffered and unbuffered IO are two implementations of the same thing.
• spacechild1 9mo ago
  > the socket API does not (really) have a function to flush the buffers and send everything out instantly, so you can use that after messages that require a timely answer. I never thought about that but I think you're absolutely right! In hindsight it's a glaring oversight to offer a stream API without the ability to flush the buffer.
• josefx 9mo ago
  I think you could try to add the flat MSG_MORE to every send command and then do a last send without it to indirectly do a flush.