Delay kicks in initial handler.

See source for reasoning
This commit is contained in:
md_5 2014-07-08 15:16:22 +10:00
parent 02cb1fc65b
commit 7347daf203

View File

@ -13,6 +13,7 @@ import java.util.logging.Level;
import javax.crypto.SecretKey; import javax.crypto.SecretKey;
import com.google.gson.Gson; import com.google.gson.Gson;
import java.util.concurrent.TimeUnit;
import lombok.Getter; import lombok.Getter;
import lombok.RequiredArgsConstructor; import lombok.RequiredArgsConstructor;
import net.md_5.bungee.*; import net.md_5.bungee.*;
@ -426,20 +427,29 @@ public class InitialHandler extends PacketHandler implements PendingConnection
@Override @Override
public void disconnect(String reason) public void disconnect(String reason)
{ {
if ( !ch.isClosed() ) disconnect( TextComponent.fromLegacyText( reason ) );
{
unsafe().sendPacket( new Kick( ComponentSerializer.toString( TextComponent.fromLegacyText( reason ) ) ) );
ch.close();
}
} }
@Override @Override
public void disconnect(BaseComponent... reason) public void disconnect(final BaseComponent... reason)
{ {
if ( !ch.isClosed() ) if ( !ch.isClosed() )
{ {
unsafe().sendPacket( new Kick( ComponentSerializer.toString( reason ) ) ); // Why do we have to delay this you might ask? Well the simple reason is MOJANG.
ch.close(); // 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 );
} }
} }