Entwickler-Ecke
Internet / Netzwerk - Zeitdifferenz zwischen OnGetSocket und OnAccept
Croissant612 - Mo 20.12.10 13:43
Titel: Zeitdifferenz zwischen OnGetSocket und OnAccept
Hallo,
ich hoffe mal, mir kann hier irgendwer einen Denkanstoß für folgende Problematik geben:
Ich versuche eine simple Socketverbindung auf einem Port zu einem Server aufzubauen. Im Einsatz ist Serverseitig eine einfach abgeleitete Form von TCustomSocket.
Programmtechnisch scheint dies auch prinzipiell zu funktionieren (Diverse Testumgebungen funktionieren klaglos). Nur bei einer Verbindungskonstellation habe ich riesige Zeitdifferenzen serverseitig zwischen dem OnGetSocket und dem OnAccepted - Event. Hat jemand den Anflug einer Ahnung, wie es zu solchen Zeitdifferenzen kommen kann?
Mit freundlichen Grüßen
Ingo
Narses - Mo 20.12.10 14:39
Moin und :welcome: im Forum!
 Croissant612 hat folgendes geschrieben  : |
| Ich versuche eine simple Socketverbindung auf einem Port zu einem Server aufzubauen. Im Einsatz ist Serverseitig eine einfach abgeleitete Form von TCustomSocket. |
Welche Komponente ist das nun genau oder was hast du verändert? Du verwendest also keinen (standard) TServerSocket bzw. TClientSocket aus der ScktComp, richtig?
| Croissant612 hat folgendes geschrieben : |
| Nur bei einer Verbindungskonstellation habe ich riesige Zeitdifferenzen serverseitig zwischen dem OnGetSocket und dem OnAccepted - Event. Hat jemand den Anflug einer Ahnung, wie es zu solchen Zeitdifferenzen kommen kann? |
Bischen wenig Infos... :? Wenn du mit asynchronen Sockets auf Event-Basis arbeitest, dann hast du alle Vor- und Nachteile des Windows-Message-Systems. :nixweiss: Die Frage ist, wie stark ist die Anwendung (konkret: der Main-Thread) ausgelastet, wenn diese Timing-Probleme auftreten? Hier liegt normalerweise der Flaschenhals beim TServerSocket (wenn man keine eigene Thread-Klasse reinhängt, läuft das alles über den Main-Thread!).
cu
Narses
Croissant612 - Mo 20.12.10 14:49
Hi,
| Narses hat folgendes geschrieben : |
| Moin und :welcome: im Forum! |
Danke :-)
| Narses hat folgendes geschrieben : |
| Croissant612 hat folgendes geschrieben : | | Ich versuche eine simple Socketverbindung auf einem Port zu einem Server aufzubauen. Im Einsatz ist Serverseitig eine einfach abgeleitete Form von TCustomSocket. |
Welche Komponente ist das nun genau oder was hast du verändert? Du verwendest also keinen (standard) TServerSocket bzw. TClientSocket aus der ScktComp, richtig? |
Prinzipiell schon. Die Ableitung besteht eigentlich nur daraus, dass der eigene Name verwendet wurde. Inhaltlich gibt es keine Unterschiede.
| Zitat: |
| Croissant612 hat folgendes geschrieben : | | Nur bei einer Verbindungskonstellation habe ich riesige Zeitdifferenzen serverseitig zwischen dem OnGetSocket und dem OnAccepted - Event. Hat jemand den Anflug einer Ahnung, wie es zu solchen Zeitdifferenzen kommen kann? |
Bischen wenig Infos... :? Wenn du mit asynchronen Sockets auf Event-Basis arbeitest, dann hast du alle Vor- und Nachteile des Windows-Message-Systems. :nixweiss: Die Frage ist, wie stark ist die Anwendung (konkret: der Main-Thread) ausgelastet, wenn diese Timing-Probleme auftreten? Hier liegt normalerweise der Flaschenhals beim TServerSocket (wenn man keine eigene Thread-Klasse reinhängt, läuft das alles über den Main-Thread!) |
Der MainThread tut gar nichts. Er läuft und lauscht. Mit Hilfe von Wireshark habe ich den Netzwerktraffic mitgeschnitten. Der Dreiwegeverbindungsaufbau geht reibungslos (Client an Server -> SYN, Server an Client ACK, Client an Server ACK). Normalerweise würde ich nach dem letzten ACK davon ausgehen, das alles gut ist und das "Accepted" Event kommt. Bei 99% aller Netzwerkkonstellationen ist das auch so. Nur bei einer nicht... und ich suche den Grund, was dafür verantwortlich sein könnte. Gibt es eventuell andere Foren/Newsgroups bei denen eine entsprechende Anfrage geeigneter platziert ist?
MfG
Ingo
Moderiert von Narses: Zitat repariert.
---
Moderiert von Narses: Beiträge zusammengefasst---
Hi,
Ergänzung: Die Verbindung läuft über eine VPN Verbindung. In eine Richtung läuft alles klaglos, in die andere nicht. Ich schätze schon, dass die Firewall da eine Rolle spielt, kann aber beim besten Willen nicht erkennen, wo die mir in die Suppe spucken könnte.
MfG
Ingo
Narses - Mo 20.12.10 15:28
Moin!
| Croissant612 hat folgendes geschrieben : |
| Inhaltlich gibt es keine Unterschiede. |
Also ist es ein TServerSocket? ;)
| Croissant612 hat folgendes geschrieben : |
| Der MainThread tut gar nichts. Er läuft und lauscht. |
Gar nichts erscheint mir sehr unwahrscheinlich, denn die Ereignisse laufen alle im MainThread auf (wenn es denn ein TServerSocket ist). :nixweiss: Hier wäre dann wohl doch mal etwas Code hilfreich. :idea:
| Croissant612 hat folgendes geschrieben : |
| Bei 99% aller Netzwerkkonstellationen ist das auch so. Nur bei einer nicht... und ich suche den Grund, was dafür verantwortlich sein könnte. |
Es ist deine Umgebung und dein Code, den wir nicht kennen. Es kann alles mögliche sein. :?
Wenn du mit Wireshark am Protokoll gelauscht hast und die passenden Pakete da sind, ist ein Problem im Umfeld der Maschine bzw. des Systems, dass nicht zeitnah die Ereignisse erzeugt, wahrscheinlich. Mehr kann ich hier aktuell nicht erraten. :lupe:
| Croissant612 hat folgendes geschrieben : |
| Gibt es eventuell andere Foren/Newsgroups bei denen eine entsprechende Anfrage geeigneter platziert ist? |
Tja, sicher kannst du gerne in anderen Foren/Usergroups anfragen, spannend ist wohl eher, wie sowohl wir als auch jemand anders aus der Nichkenntnis der Umgebung/Code auf den Fehler kommen soll... :gruebel:
cu
Narses
Croissant612 - Mo 20.12.10 15:48
Hi,
| Zitat: |
| Also ist es ein TServerSocket? |
Jo.
| Zitat: |
| Gar nichts erscheint mir sehr unwahrscheinlich, denn die Ereignisse laufen alle im MainThread auf (wenn es denn ein TServerSocket ist). :nixweiss: Hier wäre dann wohl doch mal etwas Code hilfreich. :idea: |
Der Mainthread macht in dem Augenblick echt nichts, als auf eine Verbindung zu warten. Es werden nur die Events mit einer Logausgabe ausgewertet.
| Zitat: |
| Wenn du mit Wireshark am Protokoll gelauscht hast und die passenden Pakete da sind, ist ein Problem im Umfeld der Maschine bzw. des Systems, dass nicht zeitnah die Ereignisse erzeugt, wahrscheinlich. |
Ja, das dachte ich mir :-) Ich bin auch im Blindflug unterwegs und auf der Suche nach Ideen, ob und unter welcher Voraussetzung jemand ein solches Verhalten schonmal gesehen hat.
Das System ist ein Windows 2008 Server SP2. Verbinde ich die beiden Rechner im gleichen Netzwerksegment ist alles gut.
Ich vermute, dass irgendeine Firewall oder whatever dazwischenfunkt, habe aber keinen Anhaltspunkt wonach ich suchen kann. Es scheint irgendetwas zu geben, dass das Event verzögert/verhindert. Bzw. auf Windowsebene scheint neben dem SYN - ACK Spiel noch irgendetwas anderes notwendig zu sein, um die Verbindung zu akzeptieren...
Mit freundlichen Grüßen
Ingo Horn
Narses - Mo 20.12.10 16:12
Moin!
| Croissant612 hat folgendes geschrieben : |
| Zitat: | | Gar nichts erscheint mir sehr unwahrscheinlich, denn die Ereignisse laufen alle im MainThread auf (wenn es denn ein TServerSocket ist). :nixweiss: Hier wäre dann wohl doch mal etwas Code hilfreich. :idea: |
Der Mainthread macht in dem Augenblick echt nichts, als auf eine Verbindung zu warten. Es werden nur die Events mit einer Logausgabe ausgewertet. |
Also ist schonmal zumindest eine Log-Ausgabe drin. :zwinker: Du glaubst gar nicht, was ich alles schon als "nichts" im Code vorgesetzt bekommen habe, und sei es auch nur aus Unkenntnis des Autors der Funktion des "Nichts-"Codes... :? ;)
| Croissant612 hat folgendes geschrieben : |
| Das System ist ein Windows 2008 Server SP2. Verbinde ich die beiden Rechner im gleichen Netzwerksegment ist alles gut. |
Das wiederum weist eher auf Probleme im IP-Routing hin. Schonmal einen Traceroute in der Problem-Konstellation gemacht? :idea:
| Croissant612 hat folgendes geschrieben : |
| Ich vermute, dass irgendeine Firewall oder whatever dazwischenfunkt, habe aber keinen Anhaltspunkt wonach ich suchen kann. |
Kann man machen, wenn man kein Produktions-System hat: einfach der Reihe nach die Dienste stoppen und schauen, was passiert. :idea:
cu
Narses
Croissant612 - Mo 20.12.10 16:45
Hi,
Tracert etc ist alles unproblematisch und findet mit akzeptablem Zeitverhalten statt.
Sowohl Server, als auch Clientseitig sind keinerlei Probleme auf Netzwerkebene zu sehen... Außer eben diesem merkwürdigen Verhalten, dass das onAccept Event erst elend spät kommt.
Immer noch verwunderte Grüße
Ingo
Narses - Mo 20.12.10 16:59
Moin!
| Croissant612 hat folgendes geschrieben : |
| Außer eben diesem merkwürdigen Verhalten, dass das onAccept Event erst elend spät kommt. |
In welchen Dimensionen bewegt sich "elend spät" denn eigentlich objektiv?
cu
Narses
Croissant612 - Mo 20.12.10 17:14
Hoi,
Die Differenz liegt bei sieben Sekunden. Ich habe mittlerweile den Contivity VPN Client als eventuellen Verursacher im Verdacht. Da dieser u.A. auch alle Netzwerkverbindungen, die nicht in direktem Zusammenhang mit der VPN Verbindung stehen kappt, fürchte ich, dass der auch auf der Ebene seine Finger im Spiel hat.
MfG
Ingo
Narses - Mo 20.12.10 17:27
Moin!
| Croissant612 hat folgendes geschrieben : |
| Die Differenz liegt bei sieben Sekunden. |
:shock: :hair:
| Croissant612 hat folgendes geschrieben : |
| Ich habe mittlerweile den Contivity VPN Client als eventuellen Verursacher im Verdacht. Da dieser u.A. auch alle Netzwerkverbindungen, die nicht in direktem Zusammenhang mit der VPN Verbindung stehen kappt, fürchte ich, dass der auch auf der Ebene seine Finger im Spiel hat. |
Ist denn die Verbindung, die da so lagged, die, die über den VPN-Tunnel geht? Dann ist klar, warum das im selben Netz ohne Probleme klappt. :idea:
Wie man das jetzt allerdings behebt?! Tja... :gruebel: könnte auch ein Bug im VPN-Client sein. :nixweiss:
Du könntest das mal mit blocking-socket-calls probieren, statt non-blocking, dazu wirst du allerdings den Indy-TCP-Server nehmen müssen. :nixweiss:
cu
Narses
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!