recv: Was ist, wenn die Gegenseite nicht mehr da ist?
-
epoll: Ja.
-
gibt es dazu irgend ein beispiel/tutorial?
-
Ich brauch echt eure Hilfe, weil die Zeit drängt... Soll in nun dieses ePoll nehmen? Wenn ja, wie funktioniert es überhaupt? Ich hab gar keinen Schimmer davon...
-
Die Manpage reicht aus.
-
okay danke, ich muss mir das mal genauer anschauen...
-
Da hätt ich noch ne frage: Bei epoll_wait oder select oder sonst was kann man ja ein timeout angeben, nur auf was bezieht sich das? Angenommen man hat ein timeout von 60 sekunden und 100 clients angenommen, wird dann
- das programm fortgesetzt, wenn innerhalb der 60 sekunden überhaupt keine daten eingetroffen sind oder
- ein socket für "tot" erklärt, der innerhalb der letzten 60 sekunden kein lebenszeichen erbracht hat
?ersteres wäre nämlich nutzlos für mein programm, weil später bei über 1.000 clienten immer irgendwelche daten eintreffen und ich ja nur die toten clienten rausfischen will.
MfG, Herr-Vorragend
-
Herr-Vorragend schrieb:
ersteres wäre nämlich nutzlos für mein programm, weil später bei über 1.000 clienten immer irgendwelche daten eintreffen und ich ja nur die toten clienten rausfischen will.
das klingt mir nach nem timout-setzen mit setsockopt.
-
stimmt daran hab ich gar nicht gedacht. Also brauch ich den timeout-parameter von epoll/select gar nicht. danke
-
doch den brauchst du, weil du sonst cpu zeit verschwendest.
-
Hm, versteh ich jetzt nicht, und wie behandle ich das ganze dann? Dann wird das Programm fortgesetzt obwohl gar keine Daten vorhanden sind oder wie?
-
mitm timeout blockt dein programm wenigstens nicht und es frisst keine cputime, wenns nicht sein muss.
select() returnt 0, wenns nix zu tun gibt. andere funktionen machen was aehnliches.
-
also ein timeout für recv/send wirst du ja wohl nicht brauchen da du ja deine sockets eh im non-blocking modus hast.
-
nonblocking recv/send? wozu? (rhetorische fragen)
-
(rhetorische fragen)
-
Hm, ich verstehs nicht, es ist doch sogar besser wenn das Programm bei select() still steht, als wenn es 1000 mal pro sekunde aufgerufen wird, oder? Und die sockets lass ich denk ich im blocking modus...
-
genau das wuerde ich auch machen. deswegen hat select() erst ein timeout.
-
ich dachte select friert solange das programm ein bis ein event auftritt, ist es nicht so? Zumindest kann man das bei der funktion epoll_wait vermuten...
-
ja, bei select() ist das so. die frage muesste sich eigentlich in der dokumentation klaeren...
-
dann versteh ich gar nix mehr, wozu dann noch ein timeout??? das ganze ist doch eh in einer endlosschleife, sorry ich verstehs nicht...
-
hellseher schrieb:
also ein timeout für recv/send wirst du ja wohl nicht brauchen da du ja deine sockets eh im non-blocking modus hast.
eben doch.
ich dachte mir das so:
die sockets haben alle nen timeout von sagen wir mal 300 sekunden.select wartet immer, bis ein (oder mehrere?) socket(s) was meldet und verarbeitet das. select braucht kein timout. das kann meinetwegen auch endlos warten. die sockets sollen deshalb eins haben, damit weil wenn der client per tcp connected hat und dann stundenlang gar nix mehr sendet, weil dann keiner merkt, daß das ein böser client ist.
ok, kannst auch jedesmal, wenn select erwacht und du was verarbeitest auch mal durch die liste der sockets gehen und schauen, ob ein böser client da ist. und hier hab ich mir gedacht, wenn die leute vom kernel schon timeouts für sockets anbieten, kann ich die doch nehmen. wird schon im kernel nicht tierisch ineffizient implementiert sein.ich nahm an, daß die timeouts, die mit setsockopt gesetzt werden, nicht sagen, wie lange ein blockierender call maximal stehenbleibt, sondern die sagen, wann ein socket zwangsgeschlossen wird, weil keine daten drüber laufen.