recv: Was ist, wenn die Gegenseite nicht mehr da ist?
-
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.
-
Hm, und woher weiß ich dann, ob Daten da sind? Bisher habe ich es so geregelt, dass wenn events[i].data.fd == dem socket, der "listened", ein neuer Socket angenommen wird und ansonsten mit read etwas aus dem Buffer gelesen wird, nur ich denke bei non-blocking sockets würde es dann nichts zu lesen geben, oder?
-
Soll ich nun blocking sockets nehmen oder nicht? Es funktioniert ja auch mit blockenden sockets und bei non-blocking hab ich keine Ahnung wie ich mit denen umgehen soll...
-
nimm blockende sockets und ein select(), poll(), epoll() und wie der muell sonst noch heisst
-
funktioniert nur mit glück mit blocking sockets.
-
rely, ich nehme an, du hast fuer die meinung auch gruende, weil sie sonst wertlos ist?
-
na ist doch ganz logisch. wenns irgendwo blockt dann müssen alle anderen clients warten bis die blockierung gelöst ist.
-
falsch, dafuer sorgt das select()/aehnliches. denn nur wenns auch was zu lesen gibt (also ein recv nicht blocken wuerde), dann signalisiert select() o.ae. das.
im endeffekt wartet also keiner.bitte informier dich, bevor du dir eine meinung bildest.
-
nein du liegst falsch! nur weil select/poll/epoll dir sagt das was zu lesen da ist, kann recv immer noch blocken. beim daten lesen klingt das zwar sehr unlogisch aber man kann sich auf jeden fall nicht drauf verlassen das es nicht blockt.
hier hab ich z.B. einen kommentar in einem quelltext gesehen das das unter windows 95 und 98 passieren kann: http://tangentsoft.net/wskfaq/examples/basics/select-server.cpp (Funktion ReadData)
aber spätestens beim senden von daten wird es ganz klar. die funktionen sagen dir das schreiben möglich ist, aber sie sagen dir nicht wieviel bytes.
sagen wir mal im send-puffer für den socket sind noch 5 bytes frei und du willst aber 10 schreiben, so wird send blocken.
-
hm... so hab ich das noch garnicht betrachtet... danke fuer die erleuchtung
-
Hm, und wie soll ich diese non-blocking sockets handhaben?
Wann kommt denn ein event bei select() z.B.? Und woher weiß ich dann, ob noch weitere Daten kommen?Und noch was: Kann ich bei epoll in der epoll_event struktur oder sonst wo eine von mir gesetzte id speichern? Ich müsste nämlich jedem angenommenen socket eine ganz spezielle id zuordnen, die ich später dann bei aufrufen von read() und send() wieder benötige, sonst weiß ich ja nicht, wo die daten herkommen bzw. hinsollen.
MfG, Herr-Vorragend
-
herr... du solltest einfach die vorhandene literatur konsultieren und nicht so armselige fragen stellen.
-
ja toll, gibt es ein buch "epoll für anfänger" oder wie? ^^
und bei google konnte ich auch nichts brauchbares finden, bitte postet mir dann einen link oder sonst irgendwas, ich find echt nix...
die sache mit epoll ist im moment noch wichtiger...
-
die man pages helfen.
http://www.freebsd.org/cgi/man.cgi
ist z.b. ein man page portal