SDL_Net: Daten kommen nicht imer an

[the_easterbunny]

Hallo!
Ich arbeite gerade an einem 3D-Billardspiel, wo ich momentan versuche die Netzwerkunterstützung zu implentieren(mit SDL_Net). Nur ist mir bei den Tests aufgefallen, das manchmal geschickte Daten einfach "verloren" gehen (Also wenn ich einen String schicke, kommt der manchmal nicht an).Die Funktion SDLNet_TCP_Send(...) gibt aber immer die Länge des zu sendenden Strings zurück, also dürften hier keine Probleme auftauchen. Am Server/Client läuft die Funktion "SDLNet_TCP_recv(...)" in einem eigene Thread (da diese Funktion ja solange blockiert, bis was empfangen wird, und ansonsten die 3D-darstellung nicht mehr funktionieren würde). Soviel ich weiss, sollte bei verwendung von TCP automatisch sichergestellt werden, das die Daten ankommen, im Gegensatz zu UDP wo man dies selbst machen muss. Hat jemand eine Idee wieso bei mir die Daten trotzdem nicht immer ankommen?
mfg.
the_easterbunny

[SeeksTheMoon]

bei TCP werden sowohl die richtige Reihenfolge als auch die allgemeine Ankunft der Pakete garantiert.
Wenn etwas doch nicht ankommen sollte, dann würde ich auf einen Fehler im Quellcode tippen.

Ggf hilft ein Ausschnitt aus Deinem Code weiter

[the_easterbunny]

hallo!
habe jetzt noch folgene beobachtung gemacht: je höher die prioriät des threads der "SDLNet_TCP_recv(...)" aufruft, desto größer ist die chance das eine nachricht auch ankommt...
??
mfg.
the_easterbunny

[SeeksTheMoon]

wie testest Du denn das Programm? Sind Sender und Empfänger auf dem gleichen Rechner, oder machst Du es über ein Netzwerk/Internet?

[the_easterbunny]

über netzwerk
mfg.
the_easterbunny

hab mir das ganze jetzt nochmals angesehen. Die funktion SDLNet_TCP_recv(...) empfängt ja soviele zeichen bis entweder der puffer voll ist oder das zeichen '\0' empfangen wird. bei meiner "send-funktion" wird allerdings kein '\0' oder so angehängt, könnte das der fehler sein?

[Trillian]

Vorweg: Arbeite nur mit Strings wenn du musst, da bei Strings der Speicherbedarf viel höher ist als wenn du mit Zahlenwerten arbeitest.

Dann denk dir ein Paket-Format aus. Beispielsweise könntest du im Paket-Header reinschreiben, wieviel Bytes die Nutzlast des Paketes umfasst.

Normalerweise arbeitet man nicht mit Non-Blocking IO, sondern benutzt select() o.ä. um Benachrichtigt zu werden, wann Daten gelesen oder geschrieben werden können.

Wenn du dann erfährst, dass Daten darauf warten, gelesen und verarbeitet zu werden, liest du erstmal nur den Paket-Header => du weißt, wieviele Daten noch zum Paket gehören.

Dann liest du solange bis das Paket vollständig ist.

Weiß nicht genau, wie SDL_Net funktioniert, so ^^^^ macht man es üblicherweise unter *NIX, vllt hilfts dir ja.

[the_easterbunny]

@trillian
bei SDLNet lautet der Befehl zum senden:
SDLNet_TCP_Send(TCPsock socket,int length,char *msg); (eventuell stimmt die parameterreihenfolge nicht ganz genau, hab grad die dokumentation nicht zur hand)
ich muss also "zwingend" strings senden!
mfg.
the_easterbunny

[the_easterbunny]

hallo!
nach langem herumprobieren bin ich noch auf folgende "idee" gestoßen. Mein Program arbeitet ja mit 2 Threads, und da wird der 1. thread unterbrochen während der 2. arbeitet und umgekehrt. im 1. Thread gibt es in etwa folgende funktion:

while(1)
{
result=SDLNet_TCP_recv(...)
...haufenweise befehle...
}

Jetzt kann es natürlich sein, das der 1. thread unterbrochen wird, während die befehlsfolge NACH dem SDLNet_TCP_recv() abgearbeitet wird, also das program momentan nicht auf eine "nachricht" wartet, sondern die vorherige nachricht abarbeitet. wenn jetzt aber schon eine nachricht geschickt wurde (vom "partner"), kann die ja nicht empfangen werden, da ja momentan nicht auf eine nachricht gewartet wird, oder?
mfg.
the_easterbunny

[Trillian]

Diese Funktion kriegt bestimmt keinen Pointer auf ein signed char Array übergeben, sondern einen auf einen Batzen unsigned char's :)

=> unsigned char -> Byte => du kannst beliebige Daten verschicken.
Wenn du nur Strings verschicken könntest, würde man den "length" Parameter weglassen, da Strings in C Null-terminiert sind.