Sometimes all commands are unknown

[ghost]

Issue description

Write a short description about the issue
-Sometimes all commands are unknown

Steps to reproduce the issue

-There is no step,just when server is running,and some of the players enter the command is unknown command.
-Sometimes getting out of the server can not only solve the problem,but sometimes not.
-Restart the server can solve this problem.
!!!This problem is only for some players,other players are normal.

OS and versions

• Nukkit Version: Nukkit:1.0dev API:1.0.0 protocol:100

• Java Version: 1.8.0_111

• Host OS: Linux

• Host Configuration: 4GB RAM, 35GB SSD drive, 4 core CPU from Intel, 5 Mb internet upload

• Client Edition: Windows 10 , Android

• Client Version: 1.0.0

Crashdump, backtrace or other files

• Nothing

<!--- Copy and paste your backtrace here... -->
```Nothing
* ...

[File14]

Only for IOS users.

[DaMatrix]

Can confirm on android

[ghost]

Windows10 is the same.
=-=

[ghost]

How to solve this problem?

[boybook]

It is because of the loss of AvailableCommandsPacket. It is really a big packet.
You can send it again to solve this problem.

[ghost]

But...it's no use sending it back again
Enter a / no tips

[ghost]

Now . The only way to do this is to cancel OP, and then give it back to OP to use the command!!!

[DaMatrix]

That's obvious. When permissions are changed, allowed commands are recalculated and sent to the client.

[Snake1999]

This is a serious problem. Probably it's caused by packet loss #blameUDP
I don't know how to fix because I can't get if this client received this packet successfully. Maybe think of another way?
I can reprouce in my iPhone, but I cannot reproduce in my android simulator running on windows 7.
... Still exploring

[DaMatrix]

A temporary fix would be to send the packet three or four times, just to make sure that the packet gets to the client eventually. Not very efficient though, I don't think the client reports if it receives a packet.

[MrPowerGamerBR]

@Snake1999 are you sending the avaliable commands packet as a reliable packet? It shouldn't have any packet loss if you are using RakNet + send as reliable.

(Well, if Nukkit's RakNet is properly implemented of course, reliable will try to send the packet and make sure that the packet reached it's destination)

[MrPowerGamerBR]

http://www.jenkinssoftware.com/raknet/manual/reliabilitytypes.html

Couldn't it be sent with RELIABLE_WITH_ACK_RECEIPT? MCPE should reply with a ACK receipt so you can figure out if the client did receive the packet or not.

[MrPowerGamerBR]

Well, it doesn't help that the Nukkit's Notify ACK implementation is missing, really:

    @Override
    public void notifyACK(String identifier, int identifierACK) {
    		
    }

Uhhh... where is the rest of the code?

Anyway, the client does send a ACK response if you ask it to, I will try to fix this issue by checking if the client sent a ACK response, if it doesn't resend the packet until the client receives it.

[Creeperface01]

but why this doesn't happen to chunks? Why chunk packets don't lose?

[MrPowerGamerBR]

@Creeperface01 I think it's because the chunks are compressed more nicely when sent and the available commands packet may get even bigger than a chunk packet if you have a lot of commands.

[Snake1999]

I think it might be Rak Network layer, for there is no code written for 'TCP packet resend'. Rak simulates TCP connection by UDP diagram packets, that means 'resend' should be written.
Thus, this big packet for command (for big servers even tens of kilobytes), once lost, the server does not find out this problem, and just continued its work as client confused by no command information sent.
TODO

[Snake1999]

#1406