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

Maximum transfer unit issue with official Bedrock servers #95

Closed

whirvis opened this issue Sep 11, 2018 · 0 comments

Labels

Bug v2.0

Owner

whirvis commented Sep 11, 2018

When trying to figure out what MTU to use, the client will send what MTU it wants to use until the server responds. When the server responds, it is supposed to respond with the same MTU. If the MTU is higher, then the server could end up sending data that would be cut off. If it is lower, then then packets being sent by the client could be lost by the server. However, what Bedrock does is respond no matter what MTU you send as long as yours is lower than what it is using. This causes the RakNetClient to fail during connection. As a result, the login code will have to be redone to allow RakNetClient to connect to official Bedrock servers.

whirvis added Bug Known Fix labels

whirvis closed this as completed in

00231a6

whirvis pushed a commit that referenced this issue


          Made some small changes

8b29c95

I decided to make a few changes before releasing version 2.10.3. The main changes are that I moved all the code from RakNetUtils and ArrayUtils to the RakNet class and changed the com.whirvis.jraknet.utils.map class to com.whirvis.jraknet.map.

I also made a small improvement when it comes to negotiating the MTU to use during connection: During connection, it is possible the server will respond with an MTU higher than the client was originally going to use (which is what caused bug #95) earlier. At first, I fixed this by simply ignoring this during connection unless an smaller MTU is requested by the server. From now on, it goes like this: If the server requests a higher MTU than the client was originally going to go with, the client will use that if and only if that MTU is not higher than the highest maximum transfer unit provided earlier before connection was attempted. If the server requests a lower MTU than what the client was originally going to go with, then the client will go with that. Also, when responding to OpenConnectionRequestOne, the server will now use its maximum transfer unit when responding with OpenConnectionResponseOne.

whirvis pushed a commit that referenced this issue


          Fixed #95

bfddce5

This was an easy fix, just had to change some logical statements in the SessionPreparation class. I will try and get version 2.10.3 released later today!

whirvis pushed a commit that referenced this issue


          Made some small changes

3c364e3

I decided to make a few changes before releasing version 2.10.3. The main changes are that I moved all the code from RakNetUtils and ArrayUtils to the RakNet class and changed the com.whirvis.jraknet.utils.map class to com.whirvis.jraknet.map.

I also made a small improvement when it comes to negotiating the MTU to use during connection: During connection, it is possible the server will respond with an MTU higher than the client was originally going to use (which is what caused bug #95) earlier. At first, I fixed this by simply ignoring this during connection unless an smaller MTU is requested by the server. From now on, it goes like this: If the server requests a higher MTU than the client was originally going to go with, the client will use that if and only if that MTU is not higher than the highest maximum transfer unit provided earlier before connection was attempted. If the server requests a lower MTU than what the client was originally going to go with, then the client will go with that. Also, when responding to OpenConnectionRequestOne, the server will now use its maximum transfer unit when responding with OpenConnectionResponseOne.

whirvis added a commit that referenced this issue


          Fixed #95

f532760

This was an easy fix, just had to change some logical statements in the SessionPreparation class. I will try and get version 2.10.3 released later today!

whirvis added a commit that referenced this issue


          Made some small changes

0f24fff

I decided to make a few changes before releasing version 2.10.3. The main changes are that I moved all the code from RakNetUtils and ArrayUtils to the RakNet class and changed the com.whirvis.jraknet.utils.map class to com.whirvis.jraknet.map.

I also made a small improvement when it comes to negotiating the MTU to use during connection: During connection, it is possible the server will respond with an MTU higher than the client was originally going to use (which is what caused bug #95) earlier. At first, I fixed this by simply ignoring this during connection unless an smaller MTU is requested by the server. From now on, it goes like this: If the server requests a higher MTU than the client was originally going to go with, the client will use that if and only if that MTU is not higher than the highest maximum transfer unit provided earlier before connection was attempted. If the server requests a lower MTU than what the client was originally going to go with, then the client will go with that. Also, when responding to OpenConnectionRequestOne, the server will now use its maximum transfer unit when responding with OpenConnectionResponseOne.

whirvis added a commit that referenced this issue


          Fixed #95

9f4d69c

This was an easy fix, just had to change some logical statements in the SessionPreparation class. I will try and get version 2.10.3 released later today!

whirvis added a commit that referenced this issue


          Made some small changes

dbc66a3

I decided to make a few changes before releasing version 2.10.3. The main changes are that I moved all the code from RakNetUtils and ArrayUtils to the RakNet class and changed the com.whirvis.jraknet.utils.map class to com.whirvis.jraknet.map.

I also made a small improvement when it comes to negotiating the MTU to use during connection: During connection, it is possible the server will respond with an MTU higher than the client was originally going to use (which is what caused bug #95) earlier. At first, I fixed this by simply ignoring this during connection unless an smaller MTU is requested by the server. From now on, it goes like this: If the server requests a higher MTU than the client was originally going to go with, the client will use that if and only if that MTU is not higher than the highest maximum transfer unit provided earlier before connection was attempted. If the server requests a lower MTU than what the client was originally going to go with, then the client will go with that. Also, when responding to OpenConnectionRequestOne, the server will now use its maximum transfer unit when responding with OpenConnectionResponseOne.

whirvis added a commit that referenced this issue


          Fixed #95

0d3114d

This was an easy fix, just had to change some logical statements in the SessionPreparation class. I will try and get version 2.10.3 released later today!

whirvis added a commit that referenced this issue


          Made some small changes

766ca7f

I decided to make a few changes before releasing version 2.10.3. The main changes are that I moved all the code from RakNetUtils and ArrayUtils to the RakNet class and changed the com.whirvis.jraknet.utils.map class to com.whirvis.jraknet.map.

I also made a small improvement when it comes to negotiating the MTU to use during connection: During connection, it is possible the server will respond with an MTU higher than the client was originally going to use (which is what caused bug #95) earlier. At first, I fixed this by simply ignoring this during connection unless an smaller MTU is requested by the server. From now on, it goes like this: If the server requests a higher MTU than the client was originally going to go with, the client will use that if and only if that MTU is not higher than the highest maximum transfer unit provided earlier before connection was attempted. If the server requests a lower MTU than what the client was originally going to go with, then the client will go with that. Also, when responding to OpenConnectionRequestOne, the server will now use its maximum transfer unit when responding with OpenConnectionResponseOne.

whirvis added a commit that referenced this issue


          Fixed #95

This was an easy fix, just had to change some logical statements in the SessionPreparation class. I will try and get version 2.10.3 released later today!

whirvis added a commit that referenced this issue


          Made some small changes

24ebe17

I decided to make a few changes before releasing version 2.10.3. The main changes are that I moved all the code from RakNetUtils and ArrayUtils to the RakNet class and changed the com.whirvis.jraknet.utils.map class to com.whirvis.jraknet.map.

I also made a small improvement when it comes to negotiating the MTU to use during connection: During connection, it is possible the server will respond with an MTU higher than the client was originally going to use (which is what caused bug #95) earlier. At first, I fixed this by simply ignoring this during connection unless an smaller MTU is requested by the server. From now on, it goes like this: If the server requests a higher MTU than the client was originally going to go with, the client will use that if and only if that MTU is not higher than the highest maximum transfer unit provided earlier before connection was attempted. If the server requests a lower MTU than what the client was originally going to go with, then the client will go with that. Also, when responding to OpenConnectionRequestOne, the server will now use its maximum transfer unit when responding with OpenConnectionResponseOne.

whirvis added a commit that referenced this issue


          Fixed #95

a623137

This was an easy fix, just had to change some logical statements in the SessionPreparation class. I will try and get version 2.10.3 released later today!

whirvis added a commit that referenced this issue


          Made some small changes

4f1d3c6

I decided to make a few changes before releasing version 2.10.3. The main changes are that I moved all the code from RakNetUtils and ArrayUtils to the RakNet class and changed the com.whirvis.jraknet.utils.map class to com.whirvis.jraknet.map.

I also made a small improvement when it comes to negotiating the MTU to use during connection: During connection, it is possible the server will respond with an MTU higher than the client was originally going to use (which is what caused bug #95) earlier. At first, I fixed this by simply ignoring this during connection unless an smaller MTU is requested by the server. From now on, it goes like this: If the server requests a higher MTU than the client was originally going to go with, the client will use that if and only if that MTU is not higher than the highest maximum transfer unit provided earlier before connection was attempted. If the server requests a lower MTU than what the client was originally going to go with, then the client will go with that. Also, when responding to OpenConnectionRequestOne, the server will now use its maximum transfer unit when responding with OpenConnectionResponseOne.

whirvis added a commit that referenced this issue


          Fixed #95

3db453c

This was an easy fix, just had to change some logical statements in the SessionPreparation class. I will try and get version 2.10.3 released later today!

whirvis added a commit that referenced this issue


          Made some small changes

36f72c1

I decided to make a few changes before releasing version 2.10.3. The main changes are that I moved all the code from RakNetUtils and ArrayUtils to the RakNet class and changed the com.whirvis.jraknet.utils.map class to com.whirvis.jraknet.map.

I also made a small improvement when it comes to negotiating the MTU to use during connection: During connection, it is possible the server will respond with an MTU higher than the client was originally going to use (which is what caused bug #95) earlier. At first, I fixed this by simply ignoring this during connection unless an smaller MTU is requested by the server. From now on, it goes like this: If the server requests a higher MTU than the client was originally going to go with, the client will use that if and only if that MTU is not higher than the highest maximum transfer unit provided earlier before connection was attempted. If the server requests a lower MTU than what the client was originally going to go with, then the client will go with that. Also, when responding to OpenConnectionRequestOne, the server will now use its maximum transfer unit when responding with OpenConnectionResponseOne.

whirvis added a commit that referenced this issue


          Fixed #95

71c22df

This was an easy fix, just had to change some logical statements in the SessionPreparation class. I will try and get version 2.10.3 released later today!

whirvis added a commit that referenced this issue


          Made some small changes

8d54d9f

I decided to make a few changes before releasing version 2.10.3. The main changes are that I moved all the code from RakNetUtils and ArrayUtils to the RakNet class and changed the com.whirvis.jraknet.utils.map class to com.whirvis.jraknet.map.

I also made a small improvement when it comes to negotiating the MTU to use during connection: During connection, it is possible the server will respond with an MTU higher than the client was originally going to use (which is what caused bug #95) earlier. At first, I fixed this by simply ignoring this during connection unless an smaller MTU is requested by the server. From now on, it goes like this: If the server requests a higher MTU than the client was originally going to go with, the client will use that if and only if that MTU is not higher than the highest maximum transfer unit provided earlier before connection was attempted. If the server requests a lower MTU than what the client was originally going to go with, then the client will go with that. Also, when responding to OpenConnectionRequestOne, the server will now use its maximum transfer unit when responding with OpenConnectionResponseOne.

whirvis added a commit that referenced this issue


          Fixed #95

ee135c3

This was an easy fix, just had to change some logical statements in the SessionPreparation class. I will try and get version 2.10.3 released later today!

whirvis added a commit that referenced this issue


          Made some small changes

fc57a82

I decided to make a few changes before releasing version 2.10.3. The main changes are that I moved all the code from RakNetUtils and ArrayUtils to the RakNet class and changed the com.whirvis.jraknet.utils.map class to com.whirvis.jraknet.map.

I also made a small improvement when it comes to negotiating the MTU to use during connection: During connection, it is possible the server will respond with an MTU higher than the client was originally going to use (which is what caused bug #95) earlier. At first, I fixed this by simply ignoring this during connection unless an smaller MTU is requested by the server. From now on, it goes like this: If the server requests a higher MTU than the client was originally going to go with, the client will use that if and only if that MTU is not higher than the highest maximum transfer unit provided earlier before connection was attempted. If the server requests a lower MTU than what the client was originally going to go with, then the client will go with that. Also, when responding to OpenConnectionRequestOne, the server will now use its maximum transfer unit when responding with OpenConnectionResponseOne.

whirvis added the v2.0 label

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment