MCPE-11069BungeeCord like Function / Fast Transfer - Broken in .12
Dear PE Gods,
===short version===
Issue: When client receives a disconnect packet, it tears down all UDP sessions.
Suggested solution: When the client receives a disconnect packet, only disconnect the session for that source address rather then tearing down the whole network session.
===long version & background===
In PE .11 server ops had capability to send a “strange packet” to the client which would redirect the client to another server. This could be done for example when the user clicks a sign, or walks through a portal, or any other thing tied to an event. It was flexible and gave servers BungeeCord like capabilities for game lobbies, etc.
PE .12 reacts a bit differently to the “strange” transfer packet. It redirects the user to the other server, but keeps both the current and previous UDP sessions alive, in effect ddosing the original server! If the client receives a disconnect from either server, then both sessions are terminated, rendering the solution unusable as the disconnect is "all or nothing." We could keep the client connected to both servers, but would cause network overloads.
I’m sure this behavior makes total sense on the client side, and I’m guessing no-one ever intended the strange packet to work, I just wanted to lay it out all here.
As a PocketMine server operator I'm extremely thankful for MCPE and hope you guys find a way to implement this type of functionality in a future version of the client in support of the community.
I've attached a copy of the "strange packet" written by Shoghi if you'd like to check it out. And the issue is profiled in detail here in Post #2:
https://forums.pocketmine.net/threads/current-major-core-issues-with-pm-1-6-non-php-7-build.11266/
Thanks!
Linked Issues
duplicates1
Attachments1
Created Issue:
BungeeCord like Function for Servers / Support for Fast Transfer
Dear PE Gods,
===short version===
Issue: When client receives a disconnect packet, it tears down all UDP sessions.
Suggested solution: When the client receives a disconnect packet, only disconnect the session for that source address rather then tearing down the whole network session.
===long version & background===
In PE .11 server ops had capability to send a “strange packet” to the client which would redirect the client to another server. This could be done for example when the user clicks a sign, or walks through a portal, or any other thing tied to an event. It was flexible and gave servers BungeeCord like capabilities for game lobbies, etc.
PE .12 reacts a bit differently to the “magic” transfer packet. It redirects the user to the other server, but keeps both the current and previous UDP sessions alive, in effect ddosing the original server! If the client receives a disconnect from either server, then both sessions are terminated, rendering the solution unusable as the disconnect is "all or nothing." We could keep the client connecting to both servers, but would cause network overloads.
I’m sure this behavior makes total sense on the client side, and I’m guessing no-one ever intended the magic packet to work, I just wanted to lay it out all here.
As a PocketMine server operator I'm extremely thankful for MCPE and hope you guys find a way to implement this type of functionality in a future version of the client in support of the community.
I've attached a copy of the "strange packet" written by Shoghi if you'd like to check it out. And the issue is profiled in detail here in Post #2:
https://forums.pocketmine.net/threads/current-major-core-issues-with-pm-1-6-non-php-7-build.11266/Thanks!
Attachments1
BungeeCord like Functionfor Servers / Support for Fast TransferBungeeCord like Function / Fast Transfer - Broken in .12
Dear PE Gods,
===short version===
Issue: When client receives a disconnect packet, it tears down all UDP sessions.
Suggested solution: When the client receives a disconnect packet, only disconnect the session for that source address rather then tearing down the whole network session.
===long version & background===
In PE .11 server ops had capability to send a “strange packet” to the client which would redirect the client to another server. This could be done for example when the user clicks a sign, or walks through a portal, or any other thing tied to an event. It was flexible and gave servers BungeeCord like capabilities for game lobbies, etc.
PE .12 reacts a bit differently to the “
magic” transfer packet. It redirects the user to the other server, but keeps both the current and previous UDP sessions alive, in effect ddosing the original server! If the client receives a disconnect from either server, then both sessions are terminated, rendering the solution unusable as the disconnect is "all or nothing." We could keep the client connecting to both servers, but would cause network overloads.I’m sure this behavior makes total sense on the client side, and I’m guessing no-one ever intended the magic packet to work, I just wanted to lay it out all here.
As a PocketMine server operator I'm extremely thankful for MCPE and hope you guys find a way to implement this type of functionality in a future version of the client in support of the community.
I've attached a copy of the "strange packet" written by Shoghi if you'd like to check it out. And the issue is profiled in detail here in Post #2:
https://forums.pocketmine.net/threads/current-major-core-issues-with-pm-1-6-non-php-7-build.11266/Thanks!
Dear PE Gods,
===short version===
Issue: When client receives a disconnect packet, it tears down all UDP sessions.
Suggested solution: When the client receives a disconnect packet, only disconnect the session for that source address rather then tearing down the whole network session.
===long version & background===
In PE .11 server ops had capability to send a “strange packet” to the client which would redirect the client to another server. This could be done for example when the user clicks a sign, or walks through a portal, or any other thing tied to an event. It was flexible and gave servers BungeeCord like capabilities for game lobbies, etc.
PE .12 reacts a bit differently to the “strange” transfer packet. It redirects the user to the other server, but keeps both the current and previous UDP sessions alive, in effect ddosing the original server! If the client receives a disconnect from either server, then both sessions are terminated, rendering the solution unusable as the disconnect is "all or nothing." We could keep the client connecting to both servers, but would cause network overloads.
I’m sure this behavior makes total sense on the client side, and I’m guessing no-one ever intended the magic packet to work, I just wanted to lay it out all here.
As a PocketMine server operator I'm extremely thankful for MCPE and hope you guys find a way to implement this type of functionality in a future version of the client in support of the community.
I've attached a copy of the "strange packet" written by Shoghi if you'd like to check it out. And the issue is profiled in detail here in Post #2:
https://forums.pocketmine.net/threads/current-major-core-issues-with-pm-1-6-non-php-7-build.11266/Thanks!
Dear PE Gods,
===short version===
Issue: When client receives a disconnect packet, it tears down all UDP sessions.
Suggested solution: When the client receives a disconnect packet, only disconnect the session for that source address rather then tearing down the whole network session.
===long version & background===
In PE .11 server ops had capability to send a “strange packet” to the client which would redirect the client to another server. This could be done for example when the user clicks a sign, or walks through a portal, or any other thing tied to an event. It was flexible and gave servers BungeeCord like capabilities for game lobbies, etc.
PE .12 reacts a bit differently to the “strange” transfer packet. It redirects the user to the other server, but keeps both the current and previous UDP sessions alive, in effect ddosing the original server! If the client receives a disconnect from either server, then both sessions are terminated, rendering the solution unusable as the disconnect is "all or nothing." We could keep the client connect
ingto both servers, but would cause network overloads.I’m sure this behavior makes total sense on the client side, and I’m guessing no-one ever intended the magic packet to work, I just wanted to lay it out all here.
As a PocketMine server operator I'm extremely thankful for MCPE and hope you guys find a way to implement this type of functionality in a future version of the client in support of the community.
I've attached a copy of the "strange packet" written by Shoghi if you'd like to check it out. And the issue is profiled in detail here in Post #2:
https://forums.pocketmine.net/threads/current-major-core-issues-with-pm-1-6-non-php-7-build.11266/Thanks!
Dear PE Gods,
===short version===
Issue: When client receives a disconnect packet, it tears down all UDP sessions.
Suggested solution: When the client receives a disconnect packet, only disconnect the session for that source address rather then tearing down the whole network session.
===long version & background===
In PE .11 server ops had capability to send a “strange packet” to the client which would redirect the client to another server. This could be done for example when the user clicks a sign, or walks through a portal, or any other thing tied to an event. It was flexible and gave servers BungeeCord like capabilities for game lobbies, etc.
PE .12 reacts a bit differently to the “strange” transfer packet. It redirects the user to the other server, but keeps both the current and previous UDP sessions alive, in effect ddosing the original server! If the client receives a disconnect from either server, then both sessions are terminated, rendering the solution unusable as the disconnect is "all or nothing." We could keep the client connected to both servers, but would cause network overloads.
I’m sure this behavior makes total sense on the client side, and I’m guessing no-one ever intended the magic packet to work, I just wanted to lay it out all here.
As a PocketMine server operator I'm extremely thankful for MCPE and hope you guys find a way to implement this type of functionality in a future version of the client in support of the community.
I've attached a copy of the "strange packet" written by Shoghi if you'd like to check it out. And the issue is profiled in detail here in Post #2:
https://forums.pocketmine.net/threads/current-major-core-issues-with-pm-1-6-non-php-7-build.11266/Thanks!
Dear PE Gods,
===short version===
Issue: When client receives a disconnect packet, it tears down all UDP sessions.
Suggested solution: When the client receives a disconnect packet, only disconnect the session for that source address rather then tearing down the whole network session.
===long version & background===
In PE .11 server ops had capability to send a “strange packet” to the client which would redirect the client to another server. This could be done for example when the user clicks a sign, or walks through a portal, or any other thing tied to an event. It was flexible and gave servers BungeeCord like capabilities for game lobbies, etc.
PE .12 reacts a bit differently to the “strange” transfer packet. It redirects the user to the other server, but keeps both the current and previous UDP sessions alive, in effect ddosing the original server! If the client receives a disconnect from either server, then both sessions are terminated, rendering the solution unusable as the disconnect is "all or nothing." We could keep the client connected to both servers, but would cause network overloads.
I’m sure this behavior makes total sense on the client side, and I’m guessing no-one ever intended the
magicpacket to work, I just wanted to lay it out all here.As a PocketMine server operator I'm extremely thankful for MCPE and hope you guys find a way to implement this type of functionality in a future version of the client in support of the community.
I've attached a copy of the "strange packet" written by Shoghi if you'd like to check it out. And the issue is profiled in detail here in Post #2:
https://forums.pocketmine.net/threads/current-major-core-issues-with-pm-1-6-non-php-7-build.11266/Thanks!
Dear PE Gods,
===short version===
Issue: When client receives a disconnect packet, it tears down all UDP sessions.
Suggested solution: When the client receives a disconnect packet, only disconnect the session for that source address rather then tearing down the whole network session.
===long version & background===
In PE .11 server ops had capability to send a “strange packet” to the client which would redirect the client to another server. This could be done for example when the user clicks a sign, or walks through a portal, or any other thing tied to an event. It was flexible and gave servers BungeeCord like capabilities for game lobbies, etc.
PE .12 reacts a bit differently to the “strange” transfer packet. It redirects the user to the other server, but keeps both the current and previous UDP sessions alive, in effect ddosing the original server! If the client receives a disconnect from either server, then both sessions are terminated, rendering the solution unusable as the disconnect is "all or nothing." We could keep the client connected to both servers, but would cause network overloads.
I’m sure this behavior makes total sense on the client side, and I’m guessing no-one ever intended the strange packet to work, I just wanted to lay it out all here.
As a PocketMine server operator I'm extremely thankful for MCPE and hope you guys find a way to implement this type of functionality in a future version of the client in support of the community.
I've attached a copy of the "strange packet" written by Shoghi if you'd like to check it out. And the issue is profiled in detail here in Post #2:
https://forums.pocketmine.net/threads/current-major-core-issues-with-pm-1-6-non-php-7-build.11266/Thanks!
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
![[Mojang] MissMarzenia (Aleksandra Zajac)](../../../data/assets/gravatar/missmarzenia.png){kind=small}
duplicates
No, this is a client issue but is a duplicate of MCPE-11069.
Any update on this issue? Thanks guys, i know you're busy
Hi, I also find this is an awful bug for servers and it blocks everything server owners need !
I support this report and hope everybody does !
Thanks guy
Does this bug still appear in 0.13.1? If so please respond.
Yes, it does
Hi Guys! Just checking in on this issue to see if you have any plans for implementing it. I know you guys are very busy and we (as server operators) feel as though we fill an important niche in the MCPE ecosystem? and this feature would go a long way in helping us route users on our servers. Thanks!
Still appears even in 0.14
Hi Antoine - does .14 still respond to the "strange packet"? I'm considering a UDP routing mechanism to address the UDP traffic issue.
Still occurs but moreover, the StrangePacket is no more handled by MCPE (seems to)
Using FastTransfer on ImagicalMine with MCPE 0.14 Build 3, nothing occurs!
Thanks Louis for considering this issue with me :o
Sure no problem. Ah ok I was afraid of that - I guess they've removed the packet all together now.
Can someone from the dev team comment?
Yes it is a great problem we have now...
It would be great to have a response of the Dev Team!
Or QA, bc we know they also work really hard and getting things done
This is a priority, multiplayer is the most used mode on MCPE. Letting this thing going down is dramatic for MCPE's future
Antoine - just be careful. Single player is the most important aspect to the developers. Server is secondary. This is their matter of preference and can't be argued. It's just a style, an approach, like a favorite color
Haha yes you're right but to me, this packet is the most important thing the world gave me: I obviously need it for my network that's now down since almost 5 months...
0.14.1 / 0.15 and this bug is still there
how is it going? this issue was reported almost 9 months ago and still is not fixed! so please reply
Please fix this! I want this back
We all have been waiting, and the fact is that the MCPE devs may have seen this by now. Perhaps they won't add it back unfortunately.
Just a thought, but confirmation from someone would be great.
Please comment on the linked ticket above, this one has been resolved as Duplicate.