After setting up a new server where I had to tweak about 15 settings to minimize delays I've decided that tcp is fucking shit.
Did you know that windows will delay sending TCP acks back for 200ms in hopes it has some data to send back as well in that time frame it can piggy back the ack onto?
Did you also know that for when a TCP connection is new, windows will only allow 2 packets to be sent and at large until the first ack comes in, followed by 4 for the second, followed by 8 for the third. (and this repeats if more then 200ms have gone without any traffic)
Did you know that it does both of those things at once?
This is (in part, receive window scaling bullshit is a whole nother story) why rsc downloads on servers far away from you can be so slow to start then speed up.
and that is only 3 of the settings I had to tweak.
Anywho, /rant, back to the main point
The primary reason TCP is used is because it ensures packet order, it ensures packet delivery, and it checksums the packet data to ensure it's not corrupt.
The Byond Protocol already has sequence numbers, and checksums(md5). all you would need to do to switch to udp is google some algorithms for managing when to assume a packet is lost and re-send it, and implement it.
ID:2210099
 Feb 7 2017, 11:16 pm
|
|||||||
| |||||||
There is always http://www.byond.com/forum/?post=2151809
It has the benefit of basically being tcp but none of the bullshit but the downside of having almost no documentation and still being in active dev. | |
IMO the biggest issue here is with resource downloads, and that's part of a larger discussion on how better to deliver those and to allow them to be mirrored or hosted online. If you are going to chunk the download up, send every chunk all at once and let the client inform you what it didn't get. (you could disable this for downloads done after the client joins the servers) Let tcp Receive Window Scaling handle the rest. The issue is byond is trying to do multiple things under one connection so its having to manage head of line blocking by using queues, but its not doing the tricky tcp does to increase the at large amount (receive window) until the connection is saturated meaning that no matter you do, the higher the ping the slower the theoretical max transfer is. Now, QUIC would solve this because it lets you use different "channels" in one connection, each with it's own head of line blocking queue. but QUIC has zero good documentation and only one implementation (Chrome) that is heavily abstracted such that understanding the implementation is near impossible. You could also just make two connections, a game stream connection and a "other" connection, and shunt downloads to that so that you don't have to throttle how much you put at large to avoid blocking the game stream. | |
Another way to do rsc downloads faster, is let us point to a json file on a web server with hashes (something that isn't byond32 for obvious reasons) and file paths, and use that for getting what the client doesn't have, and use the dd server for getting what the http site doesn't have (and do both at the same time for optimized speed)
(I should point out, for /tg/ at least, a lot of this is going to be a moot point in about two months, when i finish rolling out a amazon web services framework where clients connect to a bare dd server local to them that just has the rsc, then it bounces them to the real server on client/New(), basically shunting the rsc download to a local low latency server, as part of my general rollout of a webscale web framework) | |
ENET is a great UDP library. Its better than QUIC (doubly so since its documented) I see no real reason to drop TCP yet though. The ACK delay timer isn't an issue unless the latency is there (a rather significant latency mind you) and disabling nagle's algorithm further decreases this requirement. BYOND relies a lot on packet order and ensuring packets are received so UDP wouldn't really provide a performance benefit here.
If he sent the entire resource in one go he'd be unable to send potentially more important information (like dropping or aborting the transfer without closing the socket) until the resource was fully transferred. With that being said: Fixing preload_rsc would be pretty amazing. A more robust resource transferal system that didn't rely on BYONDs oh so wonderful resource system would be spectacular and speed up downloads a lot. Of course, download on demand would be nice too if it weren't a pain to implement -reliably and quickly-. | |
The answer isn't just fixing preload_rsc
I'd like to not have to use vlc/ie hacks to be able to do admins playing sounds without lagging everybody to shit. Fixing how byond sends resources in general really needs to happen. If he sent the entire resource in one go he'd be unable to send potentially more important information (like dropping or aborting the transfer without closing the socket) until the resource was fully transferred. I addressed this already. | |
preload_rsc can always be extended to support downloaded files.
But you could just pull a goonstation and use a browser for most audio stuff | |
I'd like to not have to use vlc/ie hacks to be able to do admins playing sounds without lagging everybody to shit. | |
there's no real need to use vlc
the html5 audio element is supported by like ie9 and up, so you could use that instead. just need some javascript to manipulate it | |
oh shit I lied it's ie11 and up, which is windows 7 and later but excludes linux users
| |
By default, yes. But BYOND disables Nagle's algorithm for DD-DS connections, so this doesn't apply--unless Windows is overriding the socket setting, which it shouldn't be doing under any circumstances.
This I did not know; I wonder if there's a setting to disable it.
That's not really correct. The sequence numbers aren't about preserving packet order but ensuring stream integrity. Repurposing them for UDP wouldn't work with the way they're currently structured.
I'm definitely not closing the door on UDP, but I really have no desire to switch the whole protocol over to it either. IMO the biggest issue here is with resource downloads, and that's part of a larger discussion on how better to deliver those and to allow them to be mirrored or hosted online.