recv: Was ist, wenn die Gegenseite nicht mehr da ist?
-
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.
-
aber er braucht es ja auch unter linux und das mit setsockopt geht ja nur unter windows oder nicht?
-
ne ich glaub ich hatte da was falsch verstanden...
-
Also das mit Blocking Sockets kann ich mir nur sehr schlecht vorstellen.
Wenn send/recv blocken dann müssten die anderen Sockets ja solange warten.
-
hellseher schrieb:
Also das mit Blocking Sockets kann ich mir nur sehr schlecht vorstellen.
Wenn send/recv blocken dann müssten die anderen Sockets ja solange warten.blocking sockets nimmt man manchmal, wenn man für jeden client einen eigenen thread erzeugt. dann isses ja nicht schlimm, wenn sie blocken.
-
klar, aber jetzt will er ja epoll benutzen...
-
hellseher schrieb:
klar, aber jetzt will er ja epoll benutzen...
deswegen nehmen wir auch keile blocking sockets, sonder nur timeout und select oder wasauchimmer select erstzt.