Conversation

Notices

1. Embed this notice
   feld (feld@friedcheese.us)'s status on Tuesday, 15-Oct-2024 02:19:52 JST feld
   @bob there's both datagram and stream types which are supposed to mimic some semantics of TCP and UDP. In the normal TCP/IP world the raw data going over the wire would be like the data field in the request going over the UDS.
   
   But what about everything else? Is there no encapsulation happening at all? Is it just the flags used when creating the socket that dictate the semantics?
   • Embed this notice
     feld (feld@friedcheese.us)'s status on Tuesday, 15-Oct-2024 02:24:53 JST feld

     in reply to

     • :blank:
     @i @bob is there a limit to how large a single... message (packet equivalent) can be?
   • Embed this notice
     :blank: (i@declin.eu)'s status on Tuesday, 15-Oct-2024 02:24:54 JST :blank:

     in reply to
     @feld @bob yes, it's pure data going through that file descriptor pipe. without any wrapping
   • Embed this notice
     feld (feld@friedcheese.us)'s status on Tuesday, 15-Oct-2024 02:29:02 JST feld

     in reply to

     • :blank:
     @i @bob found it, there are sysctls for this.
     
     On FreeBSD:
     
     net.local.dgram.recvspace: 16384
     net.local.dgram.maxdgram: 8192
     
     16K buffer, 8K max datagram size
     
     
     I wonder how practical it would be to crank that
   • Embed this notice
     feld (feld@friedcheese.us)'s status on Tuesday, 15-Oct-2024 02:33:16 JST feld

     in reply to

     • :blank:
     @i @bob you're not gonna communicate HTTP or SQL over a Stream though (right?), those are always gonna be Datagrams
     
     There are other hacks I've seen where deployments have set MTU on loopbacks to 64K for performance to reduce overhead, I wonder if 64K dgrams would be useful in some scenario
   • Embed this notice
     :blank: (i@declin.eu)'s status on Tuesday, 15-Oct-2024 02:33:17 JST :blank:

     in reply to
     @feld @bob yeah there's a bunch of kernel tunables to decide that not unlike MTU's, you can obviously go much bigger than jumbo frame sizes, but at some point a stream becomes less hassle and far more efficient
   • Embed this notice
     feld (feld@friedcheese.us)'s status on Tuesday, 15-Oct-2024 02:45:31 JST feld

     in reply to

     • :blank:
     @i @bob hmm I would have expected SOCK_DGRAM instead of SOCK_STREAM for this because with DGRAM you know when the sender is done sending some data
     
     but I guess maybe they found it more efficient to process a stream and figure out when e.g., a query has been completely read
   • Embed this notice
     :blank: (i@declin.eu)'s status on Tuesday, 15-Oct-2024 02:45:32 JST :blank:

     in reply to
     @feld @bob people do TCP over unix socket all the time, even postgresql does streaming instead of datagrams
     
     it's just much simpler to live with message delivery and order guarantees
   • Embed this notice
     :blank: (i@declin.eu)'s status on Tuesday, 15-Oct-2024 02:50:14 JST :blank:

     in reply to
     @feld @bob writing a protocol that shows where messages start and end is far simpler than writing a protocol that has to deal with fragmentation
     feld likes this.