Network Byte ordering - new branch?

[gitaaronc]

Hi,

I've cloned NightDriverStrip to https://github.com/gitaaronc/NightDriverStrip and created a new branch called, "network_byte_order".
When starting out with the NightDriver code I was sending commands to the ESP32 from a local machine, they weren't working as expected. The reason for the unexpected results is that I was converting to network byte order on the client side but the server side code was not converting back to host byte order. I've update the server side code to send and receive in network byte order converting in both directions. I'm not sure if this is something that everybody wants but do feel it is good practice. Such a change will require that all client side code be updated to utilize network byte ordering if not already. Simple for me as I've only just started with NightDriver and only have one basic client side project. I've included a very basic client side example utilizing network byte ordering in the samples directory. I'd like to have the branch added officially to the project and contribute regularly. Please let me know what you think.

Regards,

Aaron

[robertlipe]

I'd vote to just institutionalize what we have now and just fix the doc to say that whatever you've found claiming to be in NBO is a actually Little Endian because the whole world is little Endian. I don't particularly want to spend esp cycles unflipping what we already artificially flipped on our (presumably more capable) hosts.

…

On Sun, Feb 16, 2025, 2:14 PM gitaaronc ***@***.***> wrote: Hi, I've cloned NightDriverStrip to https://github.com/gitaaronc/NightDriverStrip and created a new branch called, "network_byte_order". When starting out with the NightDriver code I was sending commands to the ESP32 from a local machine, they weren't working as expected. The reason for the unexpected results is that I was converting to network byte order on the client side but the server side code was not converting back to host byte order. I've update the server side code to send and receive in network byte order converting in both directions. I'm not sure if this is something that everybody wants but do feel it is good practice. Such a change will require that all client side code be updated to utilize network byte ordering if not already. Simple for me as I've only just started with NightDriver and only have one basic client side project. I've included a very basic client side example utilizing network byte ordering in the samples directory. I'd like to have the branch added officially to the project and contribute regularly. Please let me know what you think. Regards, Aaron — Reply to this email directly, view it on GitHub <#691>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD376AOXD2DE4X26HAJ32QDWSDAVCNFSM6AAAAABXH5WPBKVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXHE3TINZZG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[gitaaronc]

I won't jump up and down disagreeing with your argument of wasting cycles on flipping bits. That said, my default is to send bits across the network big endian, it's been common practice for some time. Updating my client side code is easier, adding the endianness requirements to the Nightdriver documentation could save other newcomers a little bit of grief, provided they read the docs. :-)

[rbergen]

TL;DR: we settled on a packet format that suits our hardware platform well, and we're going to stick with it.

I agree we could indeed add some documentation about this. Then again, the whole packet format is now (only) documented in code, which shows that what's used are integer types of various byte/bit width. That those types are little-endian is a given, because the whole ESP32 platform is.

Regarding the "correct" byte order to use, I think Tanenbaum's quote "the nice thing about standards is that you have so many to choose from" applies. In this particular case we're already running pretty big things on very modest hardware, so I think it makes sense to not spend CPU cycles on reordering bits or bytes to convert what we have to something else, with the exact same outcome from a functional perspective. Again, we're sending packets to ESP32 controllers, so we know who we're talking to.

Lastly, there is the practical aspect of client stuff that's already out there. In this GitHub org alone, there are already at least 3 other projects that use the current packet format, and work well doing so. Rewriting those, and whatever else others have created on top that we don't even know about, requires a very strong argument that I just don't see.

All of this also means I will not adopt this as a secondary branch. If we do that with this branch then it needs to be maintained, which would take away from the limited time we have available for this and other projects. I'd consider that if there is something significant in the alternate branch that we want to keep but not merge into the main tree (as is the case with the one true secondary branch we have), but I again don't think that's the case here.

All that said, thank you for bringing this possible reason for the network packet thing not working to our attention. It's now on my radar (and documented here) in case someone else runs into a similar issue, which is helpful in itself.

[gitaaronc]

Fair enough. Will stick to little endian and leave the information here for the next new comer to the ESP32 & NightDriver code.