winsock Problem
-
Hallo,
ich habe ein riesen Problem, an dem ich noch verzweifle.
Ich würde mich sehr freuen, wenn mir jemand weiterhelfen könnte.Ich benutze die winsock.h um mit einem Server Daten auszutauschen.
Das Problem:
Unter Windows2000 funktioniert alles einwandfrei. Nur unter WinXP habe ich dass Problem.
Ich verwende 2 Funktionen, die sich gegenseitig aufrufen einmal mit send()
und einmal mit recv().
Unter XP werden jetzt aber manchmal 2 aufeinanderfolgende Pakete zu einem zusammengefasst warum auch immer ?Meine Fragen:
Wie kann ich dass verhindern?
Liegt es vielleicht am 4. Parameter(Flags) der Funktion Send? - bei mir 0?
Könnte das Problem behoben werden, wenn ich die winsock2.h benutze?Ich benötige dringend und schnell Hilfe. Ich bin über jede Anregung, Info, Tipp sehr sehr Dankbar.
Falls ich mich nicht verständlich ausgedrückt habe könnt Ihr mir ja kurz bescheid geben - ich werde dann sofort antworten.Vielen Dank im voraus
Gruß Tupo13
-
Du kannst dich unter keinem Betriebssystem darauf verlassen, dass das nicht passiert. Es dürfte eher der Normalfall sein, dass recv zusammenfasst. Es gibt keine 1-zu-1-Beziehung zwischen den Aufrufen von send und recv. Die Information, wie du die Daten bei send aufgeteilt hast, wird gar nicht transportiert.
Du musst entweder dafür sorgen, dass deine Pakete zeitlich getrennt werden (z.B. durch Bestätigungen), oder du musst dein Protokoll so anpassen, dass du die Pakete beim Empfangen wieder trennen kannst.
-
OK danke für deine Hilfe
Das Problem war nur beim senden, wenn ich 2 pakete nacheinander verschickt habe, dann ging bei XP nur ein einziges langes Paket über die Netzwerkkarte.
Habe es jetzt so gelöst wie du vorgeschlagen hast - ich warte immer erst die Antwort ab, bevor ich das nächste paket verschicke,
Danke nochmal Tupo13
-
-
Tupo13 schrieb:
Unter XP werden jetzt aber manchmal 2 aufeinanderfolgende Pakete zu einem zusammengefasst warum auch immer ?
setsockopt mit Parameter TCP_NODELAY verhindert das.
Freundlichen Gruss
Michael S.
-
falsch, -100 punkte.
-
Warum?! Bei mir tuts... zumal die MSDN und zahlreiche Seiten im Netz das gleiche sagen
"TCP_NODELAY BOOL Disables the Nagle algorithm for send coalescing. "( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcesdkr/html/wcesdkrsetsockopt.asp )
"TCP_NODELAY
The TCP_NODELAY option is specific to TCP/IP service providers. The Nagle algorithm is disabled if the TCP_NODELAY option is enabled (and vice versa). The process involves buffering send data when there is unacknowledged data already "in flight" or buffering send data until a full-size packet can be sent. It is highly recommended that TCP/IP service providers enable the Nagle Algorithm by default, and for the vast majority of application protocols the Nagle Algorithm can deliver significant performance enhancements. However, for some applications this algorithm can impede performance, and TCP_NODELAY can be used to turn it off. These are applications where many small messages are sent, and the time delays between the messages are maintained. Application writers should not set TCP_NODELAY unless the impact of doing so is well-understood and desired because setting TCP_NODELAY can have a significant negative impact on network and application performance. "( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wcesdkr/html/wcesdkrsetsockopt.asp )"TCP_NODELAY is for a specific purpose; to disable the Nagle buffering
algorithm. It should only be set for applications that send frequent
small bursts of information without getting an immediate response,
where timely delivery of data is required (the canonical example is
mouse movements)."( http://www.unixguide.net/network/socketfaq/2.16.shtml )"Nagle algorithm:
Named for its creator, John Nagle, the Nagle algorithm is used to automatically concatenate a number of small buffer messages; this process (called nagling) increases the efficiency of a network application system by decreasing the number of packets that must be sent. Nagle's algorithm, defined in 1984 as Ford Aerospace and Communications Corporation Congestion Control in IP/TCP Internetworks (IETF RFC 896) was originally designed to relieve congestion for a private TCP/IP network operated by Ford, but has since been broadly deployed. " ( http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci754347,00.html )Freundlichen Gruss
Michael S.