2
\$\begingroup\$

I just finished writing a packet builder that dynamically loads data into a data stream for eventual network transmission. Each builder operates by finding fields in a given class (and its superclasses) that are marked with a @data annotation.

When I finishing my implementation, I remembered that getFields() does not return results in any specific order.

Should reflection-based methods for serializing arbitrary data (like my packets) attempt to preserve a specific field ordering (such as alphabetical), and if so, how?

||improve this question
\$\endgroup\$
  • \$\begingroup\$ I tweaked the wording of your question to attempt to make it more broadly applicable, and less localized to your specific implementation. \$\endgroup\$ – user1430 Jul 3 '13 at 5:40
  • 1
    \$\begingroup\$ I declined the suggested off-topic close vote; yes, on the surface this is not about games, but the requirements of and best way to deal with serialization for game networking is different than what I would recommend for HPC or Web interfaces. I would answer this question differently here than I would on StackOverflow. \$\endgroup\$ – Sean Middleditch Jul 3 '13 at 18:31
  • \$\begingroup\$ @SeanMiddleditch and off-topic-suggesters: It was originally about packet handler for a game. Josh edited and generalized it. \$\endgroup\$ – Matchlighter Jul 3 '13 at 21:29
2
\$\begingroup\$

If your system can deserialize the data on the other end regardless of the field order, you don't need to enforce that order. But you probably want to anyway, because it's better.

If you have any dependency on that ordering (as in, you enumerate the results of getFields() on the receiving end and deserialize each field in succession), you had best make sure you have control over it, or you will end up tracking down a very subtle-looking bug a long way in the future. Then you'll really kick yourself. This is the most important reason to order the fields, but it will also be useful for a programmer to know the expected ordering when he or she works on the system, or its data.

There are a few downsides to some ordering methods. They have the potential to introduce diffs within the middle of the serialized data, which can make versioning a chore (append-only versioning is much easier to deal with). If you can guarantee that you won't interoperate data between versions, this is less of a concern.

It's usually hard to get reflection APIs to return results in code-declaration order. So any ordering method (alphabetical, size, name hash, whatever) will have some disconnect with the layout of the structure as read by a programmer. At least with a defined, enforced ordering you know what that disconnect will be. The ordering of getFields shouldn't be relied on and could potentially change underneath you when you least expect it.

||improve this answer
\$\endgroup\$
  • 1
    \$\begingroup\$ The advantage to a consistent ordering is that your serialization can be smaller. Deserialization is just "get next value" rather than "find out what the next value is for, then get it" - which probably won't matter on a smaller scale but absolutely matters in the AAA space. \$\endgroup\$ – Sean Middleditch Jul 3 '13 at 6:28
  • \$\begingroup\$ Thanks Josh. I guess I'll go to an alphabetical sorting, despite the disconnect between code-order and runtime-order (would be so nice if java returned in declaration order, for super-most class down, or similar), but I guess I can't have everything. \$\endgroup\$ – Matchlighter Jul 3 '13 at 15:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.