4 ms·

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 i

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...

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...