ENetHost::ConnectPeer() - Unexpected: Command length is not

lazalong
edited June 2011 in DotNet
Greetings,

Very new to Photon so the behaviour I encountered is perhaps know/normal.
(Btw is there a bug & wanted features tracker somewhere? )

I can easily trigger the peer.Service() to throw a System.ArgumentOutOfRangeException() with the HelloWorld_2 code
by launching a new instance right after closing a previous instance
(i.e. by pressing F5 less than a second after I closed the previous console.)
Not each time but if I run & close the app 3-4 times in rapid succession.

This might also cause an ENetHost::ConnectPeer() exception. Not sure how they are related. Some time the log will show this exception associated with the previous exception and some times not. See the log below.

My guess is that the server is still shutting down the previous peer connection
and respond to the new connection attempt. Am I right?

I don't think this will cause any problem in a game but... well... I just wanted to mention it.

XP machine with photon server running locally.
The complete code is the one on http://developer.exitgames.com/quicksta ... worldpart2 just before reading the part "Operations and Events"

Debug window
A first chance exception of type 'System.FormatException' occurred in System.dll
..A first chance exception of type 'System.ArgumentOutOfRangeException' occurred in mscorlib.dll

Callstack:
PhotonDotNet.dll!ExitGames.Client.Photon.EnetPeer.serializeToBuffer(System.Collections.IList commandList = Count = 0) Line 559 + 0xb bytes	C#
 	PhotonDotNet.dll!ExitGames.Client.Photon.EnetPeer.SendOutgoingCommands() Line 466 + 0xe bytes	C#
 	PhotonDotNet.dll!ExitGames.Client.Photon.PhotonPeer.SendOutgoingCommands() Line 683 + 0xb bytes	C#
 	PhotonDotNet.dll!ExitGames.Client.Photon.PhotonPeer.Service() Line 653 + 0x8 bytes	C#
>	HelloWorld_2.exe!HelloWorld1.Program.timer_Elapsed(object sender = {System.Timers.Timer}, System.Timers.ElapsedEventArgs e = {System.Timers.ElapsedEventArgs}) Line 50 + 0xb bytes	C#

Photon Log
1724: 13:06:39.843 - CENetThreadPool::Process - Exception - ENetHost::ConnectPeer() - Unexpected: Command length is not valid... Datagram: FF FF 00 02 00 00 00 AC 69 81 29 C8 02 FF 01 04 00 00 00 00 00 00 00 01 00 00 04 F6 00 00 80 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 13 88 00 00 00 02 00 00 00 02 02 FF 01 04 00 00 00 2C 00 00 00 01 00 00 04 F6 00 00 80 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 13 88 00 00 00 02 00 00 00 02  - ........i.)....................................................,....................................

---------------

Comments

  • looking at the program.cs I cannot see any disconnect call, thats the main reason for it.
    In Unity you usually call Peer.Disconnect(); to close down the connection properly whenever the application quits.
    If not the session is still open and the server will try to create another peer which may conflicts - you can handle it on
    your serverside code or make sure it does not occur. Either way it should be fine. Photon usually does not assume to handle
    to much for you, it rather leaves you more room for own modifications.

    I dunno about a bug/feature tracker or something, but if you have something neat just post it to the forums usually the discussion
    itself will show if its good idea or not.

    Cheers
  • sebako wrote:
    you usually call Peer.Disconnect(); to close down the connection properly whenever the application quits.
    Yes - this is one of of the reason I think the behaviour I encountered shouldn't be a problem. The fact that relaunching an application takes more than 1 sec (hence reaching the server timeout) is another.
    If not the session is still open and the server will try to create another peer which may conflicts
    That's what I was surprised to see.
    I would have thought that peer.Connect() would have some sort of "cookies" session preventing such conflict.
    you can handle it on your serverside code or make sure it does not occur.
    Does the documentation or samples provide an example?

    Thanks for the replay
  • Hey :)

    usually the idle timeout should have some treshold like 5 or 10 seconds or something - depending on your game.
    From my knowledge der is nothing builtin to prevent this from happening, as you have to build your own Peermanagement this makes sense...
    if exitgames would have implemented it would be to inflexible and you'd get alot of trouble with different types of games.
    I dunno about the documentation if there are any samples as I have written most of the connectionstuff myself, so I don't really use the documentation that much.
    The guys from exitgames are able to tell you more about this I think ;)

    Cheers
  • I just reproduced the issues of the original post found an explanation: There are 2 threads using methods on the peer at the same time.

    We decided against locking "everything" in the peer and as consequence, you can't use it safely from multiple threads (which is common practice, even for inbuilt DotNet objects).
    Timer and main thread are working parallel in program.cs. The timer will call Service() and the main thread waits for a key event. With bad luck, the keypress happens exactly when the peer is going through the outgoing list, destroys the list (as the program exits) and this leads to the ArgumentOutOfRangeException. Depending on the timing, this will also be the cause for connect exceptions: If the socket is destroyed in just the "right" millisecond, the client might notice and still have the time to report a broken connection during connect.

    If Service would be called in the main thread until a key is pressed, neither exception should happen.
    I think DotNet and Unity have callbacks that let you shutdown and cleanup your objects before the program exits, so you can workaround these issues.

    The log entry "Command length is not valid" is probably related to the application-exit situation. We will look into this some more and see if there is a fix.