Erkennen eines connect()-Verbindungswunsches auf Listen-Socket
-
Ich schreibe an einem Programm das durchgehend mehrere Aufgaben nacheinander bearbeitet, von denen die ein paar 100 msec dauern.
Eine dieser Aufgaben ist es, Anfragen von demselben Programm (das auf einem anderen Rechner läuft) zu beantworten (Server).
Eine weitere Aufgabe ist das Senden von Anfragen (Client).
Ein Programm ist also immer Client und Server zugleich.Jetzt stellt sich die Frage wie ich das am besten hinbekomme dass sich Client- und Server-Job nicht verpassen, aber auch nicht allzuviel Zeit mit Warten verbringen.
Im Augenblick hat mein Server einen nicht-blockierenden Socket und bricht - falls kein Verbindungswunsch ansteht - sofort ab, so dass das Programm andere Aufgaben weiterbearbeiten kann. Der Server-Job wird ca. jede 1 Sekunde aufgerufen.
Ein Client prüft nach einem connect() den errno auf EINPROGRESS (dazu reicht es dass wenn ein LISTEN-Socket vorhanden ist) und prüft dann mit einem select() ob auf den Socket geschrieben werden kann. Der Client-Job hat eine benutzerdef. Aufrufzeit (sollten aber immer einige Sekunden sein). Das Timeout f select() beträgt zwei Sekunden, so dass der Server die Client-Anfrage mit hoher Sicherheit mitkriegt.
Wenn man den Server-Job als eigenen Thread starten könnte wäre das Problem wohl gelöst, allerdings möchte ich im Augenblick Thread-Programmierung ausschließen.
Ich denke an sowas wie
- Betriebssystem erkennt Verbindungswunsch auf Port XX und sendet ein benutzerdef. Signal an das Programm...
Reines Wunschdenken, oder gibt's da 'ne Möglichkeit?
Herzlichen Dank schonmal für Tipps!
Stephan
-
Statt Threads könnte man auch Prozesse, also fork o.ä., nehmen. Ansonsten asynchrone IO.
-
Asynchrones IO war mit bisher unbekannt, aber soweit ich jetzt darüber gelesen habe sehe ich nicht wie es mir weiterhelfen kann. Es kommt offenbar erst nach dem Verbindungsaufbau zwischen Server und Client ins Spiel.
Aber das read() / write() auf Sockets mit meinen geringen Datenmengen sollte imho vernachlässigbar kleine Zeiten benötigen. Das zeitaufwendige ist der Verbindungsaufbau mit connect() + select() / accept().
-
Ok, mit den LowLevel Apis hab ich mich jetzt nicht beschäftigt. Ich hab derzeit mit Qt zu tun und da ist auch das connect/accept asynchron. Ob die Entwickler dafür unter der Haube Threads benutzt haben kann ich nicht sagen.
-
Es wäre auch zu überlegen diese drei Aufgaben in drei Prozesse aufzuteilen. Und falls diese sich irgendwie synchronisieren müssen das über IPC zu realisiseren.
-
Letzteres ist in der Tat die bisherige Praxis, auf die ich auch zurückgreifen werde. Zwischen den beiden Programmen, die eigentlich miteinander kommunizieren sollen, schalten sich nochmal zwei kleine Perl-Programm die nix anderes zu tun haben als Client bzw. Server zu sein.