8000 Timestamps read from incoming packets are in the wrong byte order and mismatch local GetTime() by a large offset · Issue #40 · larku/RakNet · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Timestamps read from incoming packets are in the wrong byte order and mismatch local GetTime() by a large offset #40

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.

Sign up for GitHub

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
Open
bluebear94 opened this issue Feb 12, 2017 · 5 comments 8000
Open

Timestamps read from incoming packets are in the wrong byte order and mismatch local GetTime() by a large offset #40

bluebear94 opened this issue Feb 12, 2017 · 5 comments

Comments

@bluebear94
Copy link
bluebear94 commented Feb 12, 2017 •
edited
Loading

This at least happens on Linux (Ubuntu 16.04), and with 64-bit timestamps enabled or disabled.
@Kiddinglife
Copy link

Not really understanding your problem.
As far as I can see, timestamps should be transformed into network order by library user.

@bluebear94
Copy link
Author

I am writing and reading them in network order using the BitStream class.

Actually, removing from Source/RakPeer.cpp the line (3799):

timeBS.EndianSwapBytes(0,sizeof(RakNet::Time));

fixes the issue. However, I'm not sure if this triggers any bugs with big-endian platforms.

@Kiddinglife
Copy link

I believe you client and server have different edian formate, one little, the other big. raknet in default uses big-endian if you enable endian swap macro. So, I am gussing the reason could be that endian-swao-macro is not enabled in either of your client and server.

@bluebear94
Copy link
Author

I'm building both the client and the server with the same library.

@ltjax
Copy link
ltjax commented Feb 10, 2018 •
edited
Loading

Yea, I have the same problem as bluebear94.
The ending swapping should be done by the BitStream on both sides... unless you have __BITSTREAM_NATIVE_END disabled.
The way I see it, you should put host byte order into BitStream and it does the conversion, since that is what RakNet does itself (see NAT punch through server for example)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ltjax @bluebear94 @Kiddinglife
0