Closed avieth closed 7 years ago
@avieth we can close this issue right? We're most likely going with the simpler approach (and can re-open if we change our minds).
@avieth we can close this issue right? We're most likely going with the simpler approach (and can re-open if we change our minds).
Yes indeed
This is related to #46 but is a bit of a departure because it introduces features that don't exactly fit the model of network-transport. It gives a parametric
QDisc t
, which takes in network-transportEvent
s and yields some values of typet
. It can be specialized toEvent
, as insimpleUnboundedQDisc :: QDisc Event
, to give the typical network-transportEndPoint
. But it can also be used to give a different kind ofEndPoint
: aTCPEndPoint t
which uses theQDisc t
to get at
when you calltcpReceive :: TCPEndPoint t -> IO t
.Included is an example of how it might be used. network-transport
Event
s are converted intoEndPointEvent
s which differ mainly in the fact that there are noReceived
orConnectionClosed
events. Instead, thePeerOpenedConnection
event includes a buffer for the input on that connection. ThisQDisc EndPointEvent
is parametrized on bounds for its buffers. A thread can be spawned to clear this buffer and do whatever it is the application must do. Input from the peer at the other end of that connection is controlled by how fast the thread can clear the buffer. If the buffer fills up faster than the handler can clear it then eventually the peer will feel the latency as we stop reading from its socket.