PandacubeFr/BungeeCord
1
0
Fork 0
Code Releases Activity

Delay kicks in initial handler.

Browse Source 
See source for reasoning
This commit is contained in:
md_5 2014-07-08 15:16:22 +10:00
parent 02cb1fc65b
commit 7347daf203
1 changed files with 18 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
proxy/src/main/java/net/md_5/bungee/connection/InitialHandler.java
View File

@ -13,6 +13,7 @@ import java.util.logging.Level;
import javax.crypto.SecretKey;
import com.google.gson.Gson;
import java.util.concurrent.TimeUnit;
import lombok.Getter;
import lombok.RequiredArgsConstructor;
import net.md_5.bungee.*;
@ -426,20 +427,29 @@ public class InitialHandler extends PacketHandler implements PendingConnection
@Override
public void disconnect(String reason)
{
if ( !ch.isClosed() )
{
unsafe().sendPacket( new Kick( ComponentSerializer.toString( TextComponent.fromLegacyText( reason ) ) ) );
ch.close();
}
disconnect( TextComponent.fromLegacyText( reason ) );
}
@Override
public void disconnect(BaseComponent... reason)
public void disconnect(final BaseComponent... reason)
{
if ( !ch.isClosed() )
{
unsafe().sendPacket( new Kick( ComponentSerializer.toString( reason ) ) );
ch.close();
// Why do we have to delay this you might ask? Well the simple reason is MOJANG.
// Despite many a bug report posted, ever since the 1.7 protocol rewrite, the client STILL has a race condition upon switching protocols.
// As such, despite the protocol switch packets already having been sent, there is the possibility of a client side exception
// To help combat this we will wait half a second before actually sending the disconnected packet so that whoever is on the other
// end has a somewhat better chance of receiving the proper packet.
ch.getHandle().eventLoop().schedule( new Runnable()
{
@Override
public void run()
{
unsafe().sendPacket( new Kick( ComponentSerializer.toString( reason ) ) );
ch.close();
}
}, 500, TimeUnit.MILLISECONDS );
}
}