3
pitaya4
44d

FUCK YOU NAGLE AND YOUR DUMB ALGORITHM!!! AND EVERYONE AT WHATEVER COMPANY DECIDED THAT DISABLING IT IS NOT SOMETHING THEY SHOULD IMPLEMENT!! WHAT THE FUCK MAN

Comments
  • 1
    For the people that don't get it: Nagle's algorithm (according to my research at least) prevents TCP (a networking protocol) from sending packets that are too small. It ends up combining some of my stuff though (I'm doing a game server that sends some of its data using JSON and it just BREAKS the parser when the fucking protocol combines 2 JSON strings)
  • 2
    @pitaya4 tcpclient nodelay.... But sounds very wrong what ya doing

    @highlight
    // Sends data immediately upon calling NetworkStream.Write.
    tcpClient.NoDelay = true;

    // Determines if the delay is enabled by using the NoDelay property.
    if (tcpClient.NoDelay == true)
    Console.WriteLine ("The delay was set successfully to " + tcpClient.NoDelay.ToString ());
  • 0
  • 3
    @pitaya4 That's a shitty parser.
  • 0
    @IntrusionCM Does nothing though https://stackoverflow.com/questions...

    Edit: I meant to say, yes it does something, but not what it should be doing.
  • 0
    @Fast-Nop No, it's not. It throws an exception after seeing text after it's done reading the JSON it was thrown. Even if that new text is JSON, it expects it to be part of the first JSON bit, but it's not, so it throws an exception. http://prntscr.com/slbfz7
  • 5
    @pitaya4 I read this stack overflow entry...

    And really.... Stackoverflow is a toxic pile of garbage.

    You're misusing TCP. That's an obvious fact.

    And if you want to reduce latency, then you'll have to implement at least a protocol.

    TCP isn't made for latency. It's made for correctness.

    And trying to be clever and fiddling with TCPs settings to try to reduce latency usually ends bad...

    There is a reason why QUIC / UDP exist. And there is a reason why most latency stuff for games uses binary protocols. You want latency? Go one stack deeper. You can have it.

    And to explain a bit better why it's not clever... Most networks dislike packet bombs (which will happen sooner or later) and then suddenly nothing will work anymore.
  • 1
    @pitaya4 If it weren't a shitty parser, it wouldn't choke on stream data. It shouldn't throw shit. It's simply misdesigned.
  • 4
    @Fast-Nop
    I'd say that's a minor detail; at the point where you're using JSON payloads over raw TCP in a game, we're definitively off the reservation. 🍿
  • 1
    @SortOfTested Nothing wrong with that if you want it raw and wiggling PRECIOUSSSSSSS, but going low-level and not even knowing shit about network protocols is bound to hit the wall face first.
  • 3
    @Fast-Nop
    Word. I'd go so far as to argue if nagle is double stuffing your data into packets like a Japanese rail employee at rush hour, you have a sloppy messaging strategy to begin with. As established in previous episodes, we handle millions of raw binary EDI messages a minute over tcp with no ill effects, no UDP condom or partitioning needed. Since TCP has a 4-tuple identity, any packet flooding is entirely on the application's author.
  • 1
    @SortOfTested that japanese railroad agent analogy made me laugh way too hard
  • 0
    Have you tried udp or websockets? I love tcp i do most of my networking stuff with it but it’s not always the best for everything (even if it kind of works).
    Do you explicitly need tcp?
  • 0
    @PreyK UDP is harder than TCP to implement but I suppose I'm going to have use that seeing as TCP just hates me
  • 0
    Regardless, there should be an option to disable Nagle's algorithm in any TCP implementation... I mean the properties exist - why don't they work!!
  • 2
    @pitaya4 Here's how you use JSON on a stream: Every message is a separate entity, either an object or an array. The parser listens on the stream, and every time when the current toplevel object's closing symbol arrived from the stream it fires an event, interrupt, callback or what have you. Then it continues to read from the stream. A proper stream-based anything doesn't make assumptions about how the stream is split up for transport. It views the stream as a byte stream, nothing more.
    And if your json parser doesn't work this way then fucking make one. It's the simplest encoding ever.
Add Comment