[C/C++] Verbindungsabbruch bei Socket

Hallo!

Wie kann ich feststellen ob die Verbindung die ich zu einem Server via Socket habe noch besteht? Ich baue also ne Verbindung auf, sende was und irgendwann bricht die Verbindung zusammen, weil meinetwegen ich meinen netzwerkstecker gezogen habe oder mein router nen reconnect gemacht hat. wie kann ich sowas festellen?

danke

Nimda05
 
diesen Timeout bekommst du relativ implizit durch ein Signal, eine error-Meldung oder (am wahrscheinlichsten) durch den Rückgabewert einer Funktion (zb im nicht-blockierendem Modus), je nachdem was du als Bibliothek verwendest. Ich kann dir wirklich nur das Buch von Stevens empfehlen, das ich im anderen Thread erwähnte :)
 
Ok. wenn alle stricke reißen werde ich mir das Buch schon holen (ist halt ganz schön teuer) aber das kann bestimmt noch ne Woche oder länger dauern.
Deshalb muss ich wissen wie ich sowas erkennen kann. Hat niemand ne Idee?
 
Mit Onlinequellen meinte ich halt auch google:
http://www.tenouk.com/Module41.html
http://www.beej.us/guide/bgnet/output/html/singlepage/bgnet.html (<-- das ist auch bekannt und wird oft referenziert)
(http://www.google.de/search?hl=de&q=c+network+programming+notice+timeout&btnG=Suche&meta= ist zB eine Möglichkeit)

Die einfachste (aber nicht wirklich kluge) Möglichkeit, die mir einfällt, ist, dass du die Timeout-Zeit heruntersetzt. Klüger wäre select, das ist aber nonblocking und nicht umbedingt einfach zu handhaben.
 
Deshalb muss ich wissen wie ich sowas erkennen kann. Hat niemand ne Idee?

Ganz einfach gesagt ( im worst case ) gar nicht !

Einfaches Beipiel :

Code:
send(socket,"String",strlen("String"),0);
while(true); // oder irgendwas anderes kompliziertes
int r = recv(socket,buffer,size_t,0);

Ein Prozess und ein Thread ! Woher willst du nun wissen, ob die Verbindung besteht ? Richtig, du weisst es gar nicht.

2. Beispiel

Code:
send(socket,"String",strlen("String"),0);
// Hier ist der Server offline
int r = recv(socket,buffer,size_t,0);

In diesem Fall bekommst du ein SIGPIPE und default mässig verabschiedet sich dein Programm ausser du machst ein

Code:
signal(SIGPIPE,SIG_IGN);

Die Frage ist ja, was du für deine Netzwerkprogrammierung verwendest, bei UPD weisst du ja nicht mal ob es ankommt, obwohl es meistens ja doch irgendwie ankommt.

Nun willst du eine Lösung haben nicht wahr ?

Meine Lösung wären Multicast Sockets ( sind etwas eleganter als ein Broadcast )

Du startest in deinem Prozess einen 2 Thread. Der Server macht z.B. jede Sekunde eine Meldung an seine Clients, z.b. "bin noch da". Diese Meldung musst du auswerten, kannst z.B. ein timeout für einen Socket setzen, wenn nach 2 Sekunden nichts ankam, läuft die Uhr ab. Versuche es nochmal und falls dann wieder nach 2 Sekunden nichts ankam, ist

- Server wohl weg
- Verbindung unterbrochen
- Netzwerk stark belastet
- Ein Fehler im Programm
- Server kam nicht dazu etwas zu schicken, falls viele Prozesse laufen
- usw. usw. usw.

Ist nicht sooo einfach die vernünftige Netzwerkprogrammierung. Empfängt dein Thread nun nichts vom Server kannst du den Prozess killen oder per Signal/Slot Verbindung bzw. Callback deinem Haupt Thread etwas signalisieren ( Boost.Signal Library ). Was ich aber überhaupt nicht empfehlen kann ist :

zb im nicht-blockierendem Modus

Sowas nennt sich Polling bzw. aktives warten und ist fast das schlimmste was man so machen kann, wenn man ständig einen Socket abfragt ohne das Daten ankommen.

je nachdem was du als Bibliothek verwendest

Für stupide Netzwerkprogrammierung benötigt man keine Bibliothek.

Die einfachste (aber nicht wirklich kluge) Möglichkeit, die mir einfällt, ist, dass du die Timeout-Zeit heruntersetzt.

Wirklich keine Kluge Idee :-D Ist im Netzwerk mal viel los, verabschieden sich dank des Timeout all deine Clients.

weil meinetwegen ich meinen netzwerkstecker gezogen habe oder mein router nen reconnect gemacht hat. wie kann ich sowas festellen?

Für sowas brauchst du keine Netzwerkprogrammierung, du musst nur schon ob dein eth* noch aktiv ist.
 
Sowas nennt sich Polling bzw. aktives warten und ist fast das schlimmste was man so machen kann, wenn man ständig einen Socket abfragt ohne das Daten ankommen.
Und einen blockierenden Socket zu haben, der nichts machen kann, solange er wartet, ist immer besser? Aus meiner Sicht nicht.

Für stupide Netzwerkprogrammierung benötigt man keine Bibliothek.
Es gibt Bibliotheken mit verschieden starken Abstraktionsschichten, man benötigt zwar sowas zwar nicht, aber es kann helfen.

Wirklich keine Kluge Idee :-D Ist im Netzwerk mal viel los, verabschieden sich dank des Timeout all deine Clients.

Ich weiß. Ich habe mir aber angewöhnt, soweit ich kann, wirklich Lösungsansätze für das Problem zu bieten, denn die ewigen "Das macht keinen Sinn"/"Das ist schwachsinn"/"Was hast du damit vor"-Aussagen, wo man die Fragen und Intensionen des OPs auseinander nehmen will, um gemäss der eigenen Ansicht etwas Sinniges zusammenzubasteln, nerven mich mittlerweile.

Ausserdem kann es vorkommen, dass der OP wirklich davon schon etwas Ahnung hat, und gerade nur nen gedanklichen Schubser braucht. So oder so, kann er mit meiner Antwort was anfangen.

grüsse :)
 
Original von menace
Sowas nennt sich Polling bzw. aktives warten und ist fast das schlimmste was man so machen kann, wenn man ständig einen Socket abfragt ohne das Daten ankommen.
Und einen blockierenden Socket zu haben, der nichts machen kann, solange er wartet, ist immer besser? Aus meiner Sicht nicht.

Auf meiner Sicht schon, da ich immer auf eine vernünftige Dispatcher/Scheduler implementation hoffe. Hat ein Thread einen blockierenden Socket wo es nichts zu lesen gibt, muss er auch nichts lesen.

Bei 100 Clients und auf jedem Socket noch non-blocking, ich möchste nicht wissen, was der Prozess an Rechenpower zieht ;-)

Es gibt Bibliotheken mit verschieden starken Abstraktionsschichten, man benötigt zwar sowas zwar nicht, aber es kann helfen.

In Java ganz nennt, ich nehme mir irgendeine Middelware und mache damit meine Sachen, aber in C++ reichen die einfachen Kommunikationsmittel doch meistens aus.

Ich weiß. Ich habe mir aber angewöhnt, soweit ich kann, wirklich Lösungsansätze für das Problem zu bieten

Sehe ich genauso.
 
Auf meiner Sicht schon, da ich immer auf eine vernünftige Dispatcher/Scheduler implementation hoffe.
Der kann vernünftig sein, aber für den Spezialfall trotzdem nicht passend. Und was machst du bei Sprachen wie ADA, wenn du mal nen eigenen Scheduler schreiben willst? :)

Bei 100 Clients und auf jedem Socket noch non-blocking, ich möchste nicht wissen, was der Prozess an Rechenpower zieht ;-)

Lieber Rechenpower ziehen, als dass er evtl. vor lauter Kontextswitchs gar nicht mehr zur Beantwortung kommt xD
 
Original von menace
Auf meiner Sicht schon, da ich immer auf eine vernünftige Dispatcher/Scheduler implementation hoffe.
Der kann vernünftig sein, aber für den Spezialfall trotzdem nicht passend. Und was machst du bei Sprachen wie ADA, wenn du mal nen eigenen Scheduler schreiben willst? :)

Es geht um C/C++ :D

Ich hätte auch keine Lust in ADA zu programmieren, aber es gibt schlimmeres !
 
Zurück
Oben