11 ms·

I've played with QUIC [1] and SCTP [2]. QUIC does not have good documentation and SCTP's userlevel library feels like it's intended on being used a certain way

I've played with QUIC [1] and SCTP [2]. QUIC does not have good documentation and SCTP's userlevel library feels like it's intended on being used a certain way (one-to-one sockets) and is easy to use incorrectly, which makes me uneasy about the quality of its code. I really wish there was a solid "TCP replacement" with optional reliability, optional ordering and multiplexing that I can run over real networks as user level code, among other features. But the view from the ground from what I've seen is that people either use TCP or build their own protocol that runs over UDP (I'm thinking about games specifically here). Am I missing an option here? Maybe I should dig into libquic and really figure out how to use it and if it can do what I want. [1] https://github.com/devsisters/libquic https://github.com/devsisters/libquic [2] https://code.google.com/p/sctp-refimpl/ https://code.google.com/p/sctp-refimpl/

Scramblejams 11y ago
Yeah, I have the same wish. JIC you haven't seen it, it covers some of the bases: http://enet.bespin.org/ http://enet.bespin.org/ IIRC I got frustrated with its (at least at the time) inability to send a packet while waiting on a packet to be received so I gave up and started writing my own spin on RFC 908.
- corysama 11y ago
  IIRC, packets on different "channels" in enet don't block each other. So, a troublesome reliable packet that needs retransmitting unusually many times won't hold up packets on other channels -reliable or not. Edit: from the docs > To combat this latency and reduce the ordering restrictions on packets, ENet provides multiple channels of communication over a given connection. Each channel is independently sequenced, and so the delivery status of a packet in one channel will not stall the delivery of other packets in another channel.
  - Scramblejams 11y ago
    I was referring to their non-thread-safe (within a single ENet instance) architecture combined with the need to block if you want to pick up a packet the moment it arrives. I have to block to receive that packet, but while I'm blocking, I can't send a packet (because ENet isn't thread safe). Now, it will let you set a receive timeout, but then you just spend a lot of time spinning.
- boardwaalk 11y ago
  enet looks quite interesting. The small, C code base is nice and the API looks clean. Thanks for linking it. I found this issue which looks related to your problem: https://github.com/lsalzman/enet/issues/23 https://github.com/lsalzman/enet/issues/23 An issue there describes a hack (sending a packet to your own socket to wake up enet_host_service). Not a terrible hack and much like the "self-pipe" trick.
  - Scramblejams 11y ago
    Yeah, it's a clever workaround. Don't think I'll go back to it though, my own protocol I've been working on has convinced me I want some of those layer violations QUIC also displays, so I can integrate encryption, authentication, handoff and other features without paying full price. And there's also the fact that I want something that runs on the BEAM VM...
vvanders 11y ago
Just about every networked game engine ends up implementing that over UDP(aside from congestion back-off).
chetanahuja 11y ago
"I really wish there was a solid "TCP replacement" with optional reliability, optional ordering and multiplexing that I can run over real networks as user level code, among other features." What's the use-case you're thinking of exactly? Why "optional" reliability and ordering? What are the cases when you'd use the reliability and when not?
- boardwaalk 11y ago
  For my own use, games. For example, multiple objects moving: The message updating the position of one taking longer than another shouldn't block the other from being handled. Also, an object being moved over time: You only care about the latest position, within reason. There are other models of simulation that aren't as loose (lock step-style for example). Other messages would not be unreliable/unordered. Important state changes, chat messages, etc. I know voice and video applications can cope with lost packets as well. This is in fact what SCTP was built for.

Scramblejams 11y ago

Yeah, I have the same wish. JIC you haven't seen it, it covers some of the bases: http://enet.bespin.org/ http://enet.bespin.org/ IIRC I got frustrated with its (at least at the time) inability to send a packet while waiting on a packet to be received so I gave up and started writing my own spin on RFC 908.

corysama 11y ago
IIRC, packets on different "channels" in enet don't block each other. So, a troublesome reliable packet that needs retransmitting unusually many times won't hold up packets on other channels -reliable or not. Edit: from the docs > To combat this latency and reduce the ordering restrictions on packets, ENet provides multiple channels of communication over a given connection. Each channel is independently sequenced, and so the delivery status of a packet in one channel will not stall the delivery of other packets in another channel.
- Scramblejams 11y ago
  I was referring to their non-thread-safe (within a single ENet instance) architecture combined with the need to block if you want to pick up a packet the moment it arrives. I have to block to receive that packet, but while I'm blocking, I can't send a packet (because ENet isn't thread safe). Now, it will let you set a receive timeout, but then you just spend a lot of time spinning.
boardwaalk 11y ago
enet looks quite interesting. The small, C code base is nice and the API looks clean. Thanks for linking it. I found this issue which looks related to your problem: https://github.com/lsalzman/enet/issues/23 https://github.com/lsalzman/enet/issues/23 An issue there describes a hack (sending a packet to your own socket to wake up enet_host_service). Not a terrible hack and much like the "self-pipe" trick.
- Scramblejams 11y ago
  Yeah, it's a clever workaround. Don't think I'll go back to it though, my own protocol I've been working on has convinced me I want some of those layer violations QUIC also displays, so I can integrate encryption, authentication, handoff and other features without paying full price. And there's also the fact that I want something that runs on the BEAM VM...

vvanders 11y ago

Just about every networked game engine ends up implementing that over UDP(aside from congestion back-off).

chetanahuja 11y ago

"I really wish there was a solid "TCP replacement" with optional reliability, optional ordering and multiplexing that I can run over real networks as user level code, among other features." What's the use-case you're thinking of exactly? Why "optional" reliability and ordering? What are the cases when you'd use the reliability and when not?

boardwaalk 11y ago
For my own use, games. For example, multiple objects moving: The message updating the position of one taking longer than another shouldn't block the other from being handled. Also, an object being moved over time: You only care about the latest position, within reason. There are other models of simulation that aren't as loose (lock step-style for example). Other messages would not be unreliable/unordered. Important state changes, chat messages, etc. I know voice and video applications can cope with lost packets as well. This is in fact what SCTP was built for.