Jump to content

  • Log In with Google      Sign In   
  • Create Account


lerno

Member Since 10 May 2004
Offline Last Active Jul 30 2014 03:58 PM

Posts I've Made

In Topic: Benchmarking servers

23 August 2013 - 04:34 PM

Write bots, have them play. See what happens.


In Topic: YAML vs JSON vs XML?

21 August 2013 - 08:47 AM

As far as I can tell, many systems are moving towards json for config etc. I can't speak for the rest, but I personally switched from xml (or xml-plists actually) to json because editing (and finding errors) is so much easier in json. Not to mention that json can be much more compact while still retaining readability.

 

My vote's for json. 


In Topic: UDP network layer must-haves?

12 August 2013 - 09:57 AM


Submitting fewer messages at a time leaves you with complete messages. Fragmenting data at a lower level (i.e. split up "binary data" agnostically of the message structure) will likely contain partial messages that can only be received by assembling fragments.
Insofar, doing this at application level is arguably cleaner and "better".

 

It does have the drawback that it breaks the abstraction. So now the application has to: 1) estimate packet size - meaning it must know the details of how the serialization works, 2) query the networking layer for maximum packet size and 3) add code fragmenting and defragmenting updates at various places (been there, done that).

 

It also means that any change in the networking layer might suddenly touch a whole lot more code than just the parts directly related to networking.

 

Doesn't sound ideal.


In Topic: UDP network layer must-haves?

11 August 2013 - 10:31 AM


Problem with a homebrew fragmentation implementation is that you don't really know when such a thing happens. At least, there is no easy way to find out. ICMP makes this work "magically" under IPv6 but you cannot easily access the info from any unprivilegued user process. Fragmentation happens automatically at the router under IPv4. You never know it happened.

 

But you're saying that MTU of 1280 should pretty much always work, so why not break your packet into such fragments to begin with? I mean, you say one should try to keep the UDP packet size down, but doing so pretty much would need you to split your packets at application level instead.

 

In some cases that can be better, but then again a custom fragmentation doesn't prevent you to do application level splitting if you want to.

 

What you say seem to support custom framentation rather than the opposite. What am I missing?


In Topic: UDP network layer must-haves?

11 August 2013 - 07:39 AM


I didn't look either, but I doubt it. I would deem myself very arrogant if I assumed that I could write a fragmentation layer that is exactly identical to how IP does it, only better. In all likelihood, it would only be worse! Carmack and the other people involved in Q3 should know better than to try such a thing.

 

From what I understand there appears to be some issues regarding IP fragmentation with different MTU. If I understand correctly then the situation is like this:

 

You send a packet of n bytes where n > MTU of your network. Let's say we send 4000 bytes and the MTU is 1500, so that gets split into 3 packets. At a later point this packet then needs to pass through a relay with an MTU of 1450, so suddenly those two first fragments are too big and the sender may either send an ICMP back with "packet too big" or fragment the packet again.

 

To avoid that, one solution would then be to make sure that each packet is small enough that it's unlikely to encounter any fragmentation until it's assembled at the recipient's.

 


That would be insane, however. If they have that much bulk data, then they'd better use TCP in the first place. UDP already allows you to send datagrams close to 64kiB in size, which is way too big for "realtime".

 

Well, it's likely to be for initial map downloads and such. It makes sense to either use TCP and UDP.


PARTNERS