TCP Connection - ACK der Gegenseite abwarten

[mentaltec]

Hallo,

kennt jemand eine Möglichkeit, bei einer nonblocking TCP-Verbindung zu bestimmen, welche Pakete von der Gegenseite ge'akt' wurden
zur Not würde auch reichen :: "alle Packete ge'ACK't" --> nichts mehr offen
und das ohne die Verbindung zu schliessen
ich will wissen, wann genau der Server ein bestimmtes Datenfragment/Kommando von meinem Client definitiv erhalten hat
ich hab leider keine Möglichkeit ein externes Programm zu nutzen wie Wireshark o.ä.; d.h. die Erkennung muss direkt in meinem Client erfolgen


wenn ich die Ack-Nummer der Gegensete hab, bräuchte ich "nur" noch die Zuordnung der packetnummer zu meinen Send Calls

Danke

[mjustin]

Zitat:

Zitat von mentaltec (Beitrag 1189774)

kennt jemand eine Möglichkeit, bei einer nonblocking TCP-Verbindung zu bestimmen, welche Pakete von der Gegenseite ge'akt' wurden

Welche Socket API wird denn verwendet, Winsock, Berkeley, ... ?

Ich könnte falsch liegen, aber wird dazu Zugriff auf Raw Sockets benötigt? Die sind durch einen nicht entfernbaren Hotfix ab Windows XP nicht mehr über Winsock nutzbar.

[nuclearping]

Zitat:

Zitat von mentaltec (Beitrag 1189774)

kennt jemand eine Möglichkeit, bei einer nonblocking TCP-Verbindung zu bestimmen, welche Pakete von der Gegenseite ge'akt' wurden

Bei non-blocking musst du ganze Befehle selber "ACKEN". Bei TCP ist es nicht nötig, einzelne Datenpakete zu "ACKEN", weil das Protokoll selber sicherstellt, dass die Paket(fragmente) da ankommen, wo sie hinsollen.

Vielleicht hilft dir ja die Overbyte "Internet Component Suite" (ICS) da weiter. Die ist komplett non-blocking und da sind etliche Beispiele mit bei.

[mentaltec]

Hi,

@mjustin
Winsock ist primär gefragt
ja, mit RAW müsste es gehen - ist aber mit Kanonen auf Spatzen - da müsste ich ja das ganze TCP selbst erfinden

@nuclearping
ich will wissen, WANN eine Bytesequence beim Server angekommen ist - nicht OB
ICS hilft nicht wirklich

hier noch ein Link, um das Problem zu verdeutlichen
http://de.wikipedia.org/wiki/Transmi...3.BCbertragung

[Klaus01]

Hallo,

ACKs/NACKs werden auf der TCP Schicht behandelt.
Wenn Du auf diese zugreifen willst kommst Du um ein RawSocket nicht herum.
Ein TCP Stack lässt Dir nur die Möglichkeit Daten in das TCP Packet zu stecken.
Wie das dann auf dem Transport gehandhabt wird bleibt dem User des Stack verborgen.

Grüße
Klaus

[Zacherl]

Benötigst du zwingend non-blocking Sockets? Die Verwendung der blocking Variante dürfte am Einfachsten die Funktionalität ermöglichen, die du benötigst.

[mentaltec]

wenn Du so fragst -> ich müsste das ganze Framwork umschreiben

deshalb frag ich vorher lieber nach :
wie genau kann das mit blocking gehen und
ist das gesicherte Erkenntnis oder nur Vermutung

weil MS sagt :
The successful completion of a send function does not indicate that the data was successfully delivered and received to the recipient. This function only indicates the data was successfully sent.

http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

mfg

[BUG]

So richtig sichergehen kannst du nur mit Bestätigungen auf Anwendungsebene.
Denn was nützt es dir, wenn TCP bestätigt, aber die Anwendung nicht genug Speicher hat, um die Nachricht zu verarbeiten.

Ich glaube kaum, dass du was finden wirst, das ohne Treiber bzw. RAW-Sockets auskommt.
Also entweder TCP selbst implementieren (~> bestehende Implementierung ändern) oder den Datenstrom abhören (WinCap).

Da klingt Protokoll auf Anwendungsebene ändern gar nicht mehr so kompliziert, oder? :mrgreen:

Im "schlimmsten" Fall ist TCP gar nicht im System implementiert, sondern läuft auf der Netzwerkkarte.

[Zacherl]

Kannst du deine Anforderungen noch etwas konkretisieren? Musst genau wissen, ob ein Paket angekommen UND korrekt verarbeitet wurde, oder reicht es evtl. das du dir sicher sein kannst, dass Paket A gesendet wurde bevor du Paket B losschickst? Im Normalfall gehe ich davon aus, dass mein blocking Request nach Funktionsaustritt korrekt behandelt bzw. zumindest korrekt gesendet wurde.

[mentaltec]

@Zacherl
es geht mehr oder weniger darum, Timingprobleme zu erkennen / fixen
sobald ich das Ack vom Server hab, ist jede weitere Verzögerung sein Problem
ich muss nur nachweisen, ob/wann der Server das Packet bekommen hat und dem kommt imho das Ack am Nächsten
dabei iss mir Wurscht, ob die ServerNIC das Ack bildet oder die Treibersoftware

@BUG
jaja neenee, der Server antwortet ja - ich hab aber die Vermutung, dass er sich dafür manchmal zu lange Zeit lässt; in der Entwicklungsumgebung kann ich das ja auch mit Wireshark prüfen, ich wollt das aber auch in das Endprodukt integrieren und dort haben wir keine Möglichkeit, zusätzliche Treiber zu installieren o.ä.

[Zacherl]

Dann bleibt dir als einzige Möglichkeit nur noch dich auf die Antwort vom Server zu verlassen. Wenn du der Ausführungsroutine bzw. deren Geschwindigkeit nicht traust, solltest du das lokal auf Serverseite messen. Dann bringt dir das ganze Ping Pong Spiel nämlich nicht viel. Wenn es dir gezielt um die Netzwerklatenz geht, arbeite nach dem Request / Response Prinzip und implementiere ein einfaches Ping System, über das du die Latenz messen kannst.

[nuclearping]

Es würde auch ungemein helfen, wenn du konkret sagst, worum es genau geht und was du genau machen willst / musst.

Wenn du non-blocking verwenden "musst", wurden dir die Möglichkeiten ja schon genannt. Also bleibt dir fasst nur die Möglichkeit, dein Protokoll um ein ACK vom Server zu erweitern, oder wie Zacherl sagte: Ein Request<>Response-Prinzip. Deswegen auch der Vorschlag, dir mal ICS anzuschauen, eben weil du da etliche Beispiele hast, die genau das machen - entweder direkt oder indirekt.

Das WENN und OB hebt sich somit auch gegenseitig auf.

Genauso auch wenn du dein Framework auf Blocking umschreibst.

:glaskugel:

[mjustin]

Zitat:

Zitat von mentaltec (Beitrag 1189774)

Hallo,
kennt jemand eine Möglichkeit, bei einer nonblocking TCP-Verbindung zu bestimmen, welche Pakete von der Gegenseite ge'akt' wurden

Gegenseite heisst dabei natürlichh "der Kernel der Gegenseite", also deren TCP Stack.

Es bedeutet aber nicht, dass die serverseitige Anwendung die Pakete komplett erhalten hat, denn das kann über ACK nicht festgestellt werden.

How can I explicitly wait for a TCP ACK before proceeding?

[sx2008]

Zitat:

Zitat von mentaltec (Beitrag 1189987)

es geht mehr oder weniger darum, Timingprobleme zu erkennen / fixen
sobald ich das Ack vom Server hab, ist jede weitere Verzögerung sein Problem
ich muss nur nachweisen, ob/wann der Server das Packet bekommen hat

Ist das dein eigentliches Problem?
Festzustellen, ob der Server schnell genug arbeitet oder ob er trödelt?
Nun, eine Erweiterung im Protokoll auf Anwendungsebene wurde ja schon vorgeschlagen.
Dazu müsste jede Message an den Server eine fortlaufende Nummer bekommen.
Der Server könnte dann eine Quittung mit dieser Nummer an den Client senden und zwar zu 2 verschiedenen Zeitpunkten:
1.) Message vollständig empfangen
2.) Message verarbeitet

Aber es gibt auch noch eine einfachere Lösung:
Der Server schreibt beim Empfang einer Message in eine Logdatei und ebenfalls nach Verarbeitung der Message.
Auch hier wäre eine Durchnummerierung der Messages sinnvoll.
Oder man zählt die Bytes mit:

Code:

Zeit         | Client            |Byte     |Info
=====================================================
10:13:50.950 | 192.168.1.26:5078 | 0       | Received
10:13:51.120 | 192.168.1.26:5078 | 0       | Done
10:13:56.230 | 192.168.1.26:5078 | 178     | Received
10:13:56.305 | 192.168.1.67:4088 | 2301    | Received
10:13:56.980 | 192.168.1.26:5078 | 178     | Done
10:13:58.675 | 192.168.1.67:4088 | 2301    | Done

In dem Beispiel hat der Server 3 Messages von 2 Clients empfangen und verarbeitet.
Mit so einer Logdatei (sollte abschaltbar sein) kann man Performanceprobleme gut feststellen.

[mentaltec]

ich befürchte, der Serverbetreiber wird sein Protokoll nicht wegen mir umstellen,
nur damit ich beweisen kann, dass er zeitweise inakzeptable Latenzen hat

aber ich sehe schon, das läuft auf einen RAW Socket hinaus - kann ich den eigentlich parallel zum existierenden TCP-Socket betreiben (so als LauschSocket) oder muss ich den ganzen Datentranfer darüber ziehen?
ich hab gelesen, dass MS die Fähigkeiten von RAW Sockets "limitiert" hat -- hat da jemand Erfahrung
mein Client MUSS mit allen Win Versionen ab Vista laufen - da muss ich mich also auf das kleinste gemeinsame Übel einrichten
Win/PCap kann ich nicht installieren

[Zacherl]

Da hast du Recht, ab XP SP1 meine ich, wurden die RAW Sockets limitiert. Ich befürchte die kannst du nicht mehr verwenden um eigene Pakete zu verschicken. Hintergrund davon war es, IP Spoofing und SYN Flood von Windows Systemen aus schwieriger zu gestalten. Unabhängig davon würde dir ein ACK Paket aber auch nicht viel mehr sagen, als ein einfaches ICMP Echo PING Paket an den Server.

[BUG]

Abgesehen davon, dass eine eigene TCP-Implementierung fast sicher langsamer und sicher fehlerhafter als eine Fertige ist.
Das könnte dein Programm mehr bremsen als der lahme Dienstanbieter.

Die Latenzen, die dich interessieren, sind eigentlich die auf Anwendungsebene (dh. Zeit zwischen deiner Aktion und gewünschter Reaktion).
Vielleicht noch abzüglich der mit einem Ping gemessenen Round-Trip-Time.
Das sollte doch mit clientseitigem Logging zu messen sein.