Das Problem ist nun gelöst, indem ich sicherstelle, dass NetworkServerEvent nie parallel mit anderen Netzwerkbefehlen aufgerufen wird. Vorher war es möglich, dass beim einem Aufruf von NetworkServerEvent die Client-ID ungültig gemacht wurde, was natürlich schlecht ist, wenn zur gleichen Zeit irgendwas mit diesem client gemacht wird. Was genau intern passiert kann ich nicht sagen, es kann sein, dass das Problem unabhängig vom Multithreading existiert. Also es reichen würde Netzwerkbefehle mit gerade abgelaufenen Client-IDs zu bombadieren, bis es crasht. Oder es kann sein, dass nur der gleichzeitige Zugriff auf Netzwerkbefehle Probleme macht, unabhängig ob die IDs noch gültig sind oder nicht. Letztendlich weiß Fred ob die Befehle ein Problem mit Multithreading haben, oder ob nur die Dokumentation angepasst werden muss.Wenn ein Server ein #PB_NetworkEvent_Disconnect Ereignis empfängt, wird seine zugehörige Client-Verbindung automatisch geschlossen und CloseNetworkConnection() muss in diesem Fall nicht aufgerufen werden.
Ich habe deinen Thread im englischen Forum erst jetzt gesehen. Eventuell hilft es auch bei dir, den Zugriff auf Netzwerkfunktionen per Mutex einzuschränken.mk-soft hat geschrieben:Das senden mit SendNetworkData oder SendNetworkString von einen anderen Thread auf einer nicht mehr vorhanden Connection Crash bei macOS
Ist also nen typischer übersetzungsfehler: must not --> muss nicht anstatt darf nicht :/When a server receives a #PB_NetworkEvent_Disconnect event its associated client connection is automatically closed and CloseNetworkConnection() must not be called in this case.
Code: Alles auswählen
Repeat
LockMutex(ServerMutex)
Event = NetworkServerEvent(\ServerID)
If Event
ConnectionID = EventClient()
keyConnectionID = Hex(ConnectionID)
EndIf
UnlockMutex(ServerMutex)
Select Event
Ganz unabhängig von der Implementation, der WebSocket standard ist paketbasiert. Das heißt, alle gesendeten Pakete kommen in der Reihenfolge und Größe an, wie sie gesendet wurden. Und das entweder ganz oder garnicht. Auch die Größe eines Pakets ist quasi uneingeschränkt (~9,22 EB), aber in meiner lib habe ich ein Standardlimit von 10 MB pro Paket, das ist aber konfigurierbar. (Clients werden zwangsgetrennt, wenn das Limit überschritten wird)mk-soft hat geschrieben:Frage:
Kümmerst sich das Java WebSocket sich darum das die Daten bis 64kB vollständig einmalig übergeben werden, oder muss man sich selber darum kümmert das die Daten alle angekommen sind?
Ich hatte gedacht, es stürzt dort auf der Client-Seite ab, wo kein Mutex vorhanden ist um NetworkClientEvent und SendNetworkData zu serialisieren. Oder hast du auf der Server-Seite trotz Mutex auch Probleme mit NetworkServerEvent auf MacOS? Aber vollkommen unabhängig davon muss Fred irgendwas beheben. Im Idealfall sollte die Netzwerklib korrekt Threadsafe sein.mk-soft hat geschrieben:Da ich mir nicht sicher bin das intern alles Threaded ist, mache ich das mit den Events so.
Code: Alles auswählen
len = 0
LockMutex(MutexSend)
Repeat
cnt = SendNetworkData(ConnectionID, SendBuffer + len, size - len)
len + cnt
Until len = size Or cnt < 0
UnlockMutex(MutexSend)