Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Slight refactor to make the code handling PACKET_UDP_MASTER_RESPONSE_LIST cleaner #1603

Closed
DorpsGek opened this issue Dec 29, 2007 · 5 comments
Closed

Slight refactor to make the code handling PACKET_UDP_MASTER_RESPONSE_LIST cleaner #1603

DorpsGek opened this issue Dec 29, 2007 · 5 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay

Comments

@DorpsGek
Copy link
Member

pvz opened the ticket and wrote:

While learning about the server browser protocol for a program I'm writing, I noticed some rather confusing code which wasn't too easy to figure out, since the code was uncommented and misleading.

The thing is -- the protocol used by OpenTTD for some reason sends the IP addresses of the servers in network byte order on the wire. However, your wrapper functions used by the network code don't give the user an option of pulling ints in network byte order off the wire -- instead the only possibility is using Packet::recv_int32, which converts from little-endian to host byte order.

This means that, in fact, you're guaranteed to get architecture-specific opposite byte order. To convert this into something usable -- network byte order, TO_LE32(!) was wrapped around it to swap from archiecture-specific opposite byte order into network byte order.

I made a patch to replace this with some clearer code, so that future adventurers might not be confused in the same way. :-) (As a bonus, it no longer performs two pointless byteswaps on a big-endian machine.)

Attachments

Reported version: 0.6.0-beta1
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/1603
@DorpsGek
Copy link
Member Author

DorpsGek commented Jan 1, 1970

Anonymous closed the ticket.

Reason for closing: Not a bug

This comment was imported from FlySpray: https://bugs.openttd.org/task/1603

@DorpsGek DorpsGek closed this as completed Jan 1, 1970
@DorpsGek
Copy link
Member Author

Rubidium wrote:

I'm not in favour of this change because it removes the "don't care about endianness and stuff for the network protocol". What I mean with this is that the packet 'system' should be seen as a black box without internal knowledge about it; we might easily change it to something else. Adding '_noswap' removes the black box from the packet system.

Furthermore doing the '_noswap' makes it much easier for people to do 'the wrong' thing with the packet, i.e. assume that it always 'swaps' the data in the packet for the ones without '_noswap' and assume that the value is always the same on every platform (people do not read the documentation and that's a fact).

This comment was imported from FlySpray: https://bugs.openttd.org/task/1603#comment3096

@DorpsGek
Copy link
Member Author

pvz wrote:

Okay. In that case, what if I rewrote the method to be a more general "read n bytes into pointer" deal? Then i could do something like:

p->read_bytes_into_pointer(&ipaddr, 4) or something. That would also kinda break the endianness barriers, but would do it in a way that doesn't invite abuse.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1603#comment3110

@DorpsGek
Copy link
Member Author

Rubidium wrote:

"Oh... I need to read an array of uint16s. What shall I uses? Lets use p->read_bytes_into_pointer(array, sizeof(array)) as that looks like it's doing what I want and it's easier than looking and calling p->read_uint16."

Not quite a scenario where abuse isn't invited.

This comment was imported from FlySpray: https://bugs.openttd.org/task/1603#comment3111

@DorpsGek
Copy link
Member Author

pvz wrote:

In that case, I guess we can just read the IP address directly into memory byte for byte using Recv_uint8 four times. That way no abusable functions are added to the Packet interface. A patch reflecting this style has been uploaded as master-response-list-endian-refactor3.diff

Attachments

This comment was imported from FlySpray: https://bugs.openttd.org/task/1603#comment3115

@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay labels Apr 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@DorpsGek