-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unhandled Exception:GNet error, ENET_EVENT_TYPE_RECEIVE with invalid peer #294
Comments
This means that program receiced something from a peer it does not know (anymore..possibly).
You might print out to the log/console if peers disconnect. So you could check if something disconnects before it happens.
Dunno if enet packets are in order but if not it can happen that a disconnect happens before another packet of that peer is received.
Also a disconnect could happen because of a timeout... This will disconnect the peer and remove it.
Yet the peer/other client does not know about the disconnect yet and answers an request / sends a packet.
Thus the brl.gnet logic is wrong in what it does there. It should simply ignore incoming data from unknown peers, not erroring out.
Else this would allow to crash servers this way.
If that is how I assume it is it would proof that brl.gnet was never used seriously in products with a higher user base.
|
i thought this happens when a second peer connects but it is not, it is when data is set. it seems to connect but i am not sure when the error occurs let me do some debugging |
Find out when it happens. Replicate it. And then check if it disconnects before ..as disconnect_timeout/disconnect is the only way a peer will be removed from the host.
So maybe in your code you create a new host somewhen...and of course it won't know the peers then.
Or something resets the peer list...
These are the things you should try to fiddle out so someone could possibly assist fixing.
|
okay i've tested creating host, connecting to gnet and creating an object. no issue there. i shall review next session of code in debug mode. |
when i step into gnetsync stepping every line it has no error but, after gnetsync(host) without stepping into every line, it lands on the throw exception error above, on line scangnet function (custom client function) which receives which objects created, modified and closed and collects floats of those objects to act accordingly. like getgnetfloat, later, before syncing, floats are set.. i was thinking perhaps it is trying to get such information before syncing that its throwing an error. the client does a series of gathering floats and setting them if they're different than the clients. i do not understand and have the time if you dont either. |
In release mode no gnet error happens. and everything works as intended, including disconnect timeout. debug mode is important and the previous error/enet error has been resolved with the latest gnet brl.mod merge. |
~>Unhandled Exception:GNet error, ENET_EVENT_TYPE_RECEIVE with invalid peer
~>
tb
bt
~>
tb
~>StackTrace{
~>@/home/william/Documents/GitHub/MedievalDreams.io/Server.bmx<30,0>
~>Function Server
~>Global Host:TGNetHost=$00007f58e958ffa0
~>Global listen:Int=1
~>Global shutdown:Int=1
~>Local inputthread:TThread=$00007f58e956cd20
~>Local ServerMilliseconds:Int=69843000
~>@/home/william/Documents/GitHub/MedievalDreams.io/Server.bmx<28,0>
~>Local
~>@/home/william/Desktop/BlitzMax/mod/brl.mod/gnet.mod/gnet.bmx<835,0>
~>Function GNetSync
~>Local host:TGNetHost=$00007f58e958ffa0
~>@/home/william/Desktop/BlitzMax/mod/brl.mod/gnet.mod/gnet.bmx<539,0>
~>Function Sync
~>Local Self:TGNetHost=$00007f58e958ffa0
~>Local succ:TLink=Null
~>@/home/william/Desktop/BlitzMax/mod/brl.mod/gnet.mod/gnet.bmx<482,0>
~>Local
~>Local ev:ENetEvent=$00007f58e952cfa0
~>Local peer:TGNetPeer=$00007f58e958edc0
~>@/home/william/Desktop/BlitzMax/mod/brl.mod/gnet.mod/gnet.bmx<485,0>
~>Local
~>@/home/william/Desktop/BlitzMax/mod/brl.mod/gnet.mod/gnet.bmx<497,0>
~>Local
~>@/home/william/Desktop/BlitzMax/mod/brl.mod/gnet.mod/gnet.bmx<498,0>
~>Local
~>Local msg:TGNetMsg=Null
~>}
~>
The text was updated successfully, but these errors were encountered: