The status is that nothing's been done on it. Also in theory it's possible to do STUN-like tricks to connect two peers behind NATs via UDP by playing certain small tricks (like STUN does). reduce speed when link becomes busy and round-trip times are getting high, more packets getting lost, etc). On other hand UDP-based protocol can provide low-level link status data (like round-trip times and packets loss rate) quite easily so it's possible to dynamically readjust speeds according to actual state of things (i.e.
There is not much you can do with TCP about this issue. Routers would use their own algos to (re)schedule your (buffered) data packets queued in their queues.Ģ) As the result, usually you have too much stuff in output buffers of router and awfully bad ping times since there is ton of TCP connections who can't accurately measure state of link and transmit direction getting jammed on DSL and similar slow-send links. Router usually lacks 100MBps link to Internet and hence have to buffer all your data if they arrive fast and send them as actual connection rate permits (and it's much slower than 100MBps).ġ) Your scheduling efforts for TCP are useless in many configurations. But then packets hit router(s) which have to forward them to ISP. Look, you can do whatever you want on local machine with it's scheduling, BUT that's where one problem occurs: what if there is router on the way? You can schedule packets on fast local 100MBps link to router as you want them to. Set congestion control algorithm: Resource temporarily unavailableĪs for me, any attempts to do something with TCP flow control looks like a fruitless effort. Set congestion control algorithm: Success Set congestion control algorithm: Operation now in progress
In both places from your patch and it printed these things: Printf( "Set congestion control algorithm: %s\n",
But on practice anyway then not much difference at least here.Ĭan you confirm that the code actually triggered? Did you have any warnings about being unable to set congestion control in the log? It only requires that the receiver implement TCP timestamps (RFC 1323). Hydri says that tcp-lp requires support on the both ends What are your ping times like during the transfer?