recv: Was ist, wenn die Gegenseite nicht mehr da ist?
-
c.rackwitz schrieb:
(1) vor dem includen der entsprechenden header die groesse der fdsets mittels eines defines aendern (man select ist die autoritaet)
Du weisst aber schon, dass FD_SETSIZE vom System festgelegt wird, oder?
-
The default size of FD_SETSIZE is currently 1024. In order to accommo-
date programs which might potentially use a larger number of open files
with select(), it is possible to increase this size by having the program
define FD_SETSIZE before the inclusion of any header which includes
<sys/types.h>.ich weiss ja nicht, wie das auf anderen systemen ist aber in dem fall wuerd ich mich einfach mal mit der doku zum system hinsetzen und die lesen...
jetzt mal im ernst. war dir einfach nicht danach, selber mal nach antworten zu suchen?
-
c.rackwitz schrieb:
jetzt mal im ernst. war dir einfach nicht danach, selber mal nach antworten zu suchen?
Hab ich gemacht. In Posix steht nichts dazu, also muss es wohl 'ne unportable Erweiterung von FreeBSD sein.
-
da sockets nicht zu ANSI C gehoeren, stellt sich mir die frage nach "plattformunabhaengiger programmierung" nicht mehr. allein die socketheader fuer unix und windows sind verschieden. da machts auch nichts weiter aus, sich auf select(), poll() oder WaitForMultipleShit() festzulegen, wenn man sowieso auf an gewisse plattformen gebunden ist.
-
epoll
-
aio
-
Also mit der Platform ist das so ne Sache, wär schon schön wenn es auf Unix und Windows laufen würde, weil ich untern Windows entwickele und das Programm später auf dem Server unter Unix laufen soll.
Also FD_SETSIZE ist bei mir auch auf 64 festgelegt. Kann ich es denn einfach größer definieren?
Und also irgendwie find ich mein Konzept gar nicht mal soo dumm. Bei 2.000 Usern gibt es unter Windows kein Problem. Das Programm belegt dann ca. 20 MB Speicher. Ist das eurer Meinung nach zu viel? Hab mir überlegt, dass ich das Programm dann später einfach mehrfach über verschiedene Ports laufen lasse, sodass ich dann auch mit 10.000 Usern problemlos zurech komme.
Oder sind diese Werte schlecht bzw. verbesserbar?
-
-
ja das mit den 2.000 Threads als Grenze ist mir auch aufgefallen. Allerdings hilft mir folgendes auch nicht weiter:
HANDLE h = CreateThread(NULL, 4096, ThreadProc, NULL,
STACK_SIZE_PARAM_IS_A_RESERVATION, &id);da ich nicht in der WinAPI programmiere (sondern mit pthread, was eben auf Windows _und_ Unix läuft).
-
Hast du schon mit 2000 Clients getestet?
-
ja und es funktioniert
-
ich flehe dich an, nimm select(), poll() oder waitformultipleshit(). kapsele es wenn noetig und mach preprocessor directives drum herum fuer bedingte compilierung.
aber um gottes willen benutz keine 2000 threads. das ist overkill.
-
ja ist ja gut
Aber trotzdem funktioniert select() nur mit 64 Usern. Oder ist es später bei Debian Linux anders? DORT muss es dann mit 2.000 Usern fertig werden, kann ich denn einfach so FD_SETSIZE erhöhen ohne Komplikationen?
MfG, Herr-Vorragend
-
Hab grad gesehen, dass auf Debian FD_SETSIZE auf 1.024 gesetzt ist. Kann ich diesen Wert nun einfach auf z.B. 4.096 erhöhen?
-
Herr-Vorragend schrieb:
hm, also SO_RCVTIMEO ist nur in Windows verfügbar und in Unix nicht, fällt also schon mal weg.
oh, wußte gar nicht, daß es sowas schönes gibt.
ok, ich werde meine sockets unter win mit SO_RCVTIMEO ausstatten. das erspart mir viel ärger.und nn zu der linux-these.
ich tippe "man 7 socket" ein und er sagt mir
[quote=Linux 2.6.11-co-0.6.3-pre13]SO_RCVTIMEO and SO_SNDTIMEO
Specify the receiving or sending timeouts until reporting an error. The parameter is a struct
timeval. If an input or output function blocks for this period of time, and data has been sent or
received, the return value of that function will be the amount of data transferred; if no data has
been transferred and the timeout has been reached then -1 is returned with errno set to EAGAIN or
EWOULDBLOCK just as if the socket was specified to be nonblocking. If the timeout is set to zero
(the default) then the operation will never timeout.[/quote]
das sieht mir danach aus, als könne ich das nehmen. das erspart mir ja ungemein viel select-ärger.
-
hm, komisch die MSDN sagt:
BSD options not supported for setsockopt are shown in the following table.
...
SO_RCVTIMEO int Receives time-out in milliseconds (available in the Microsoft implementation of Windows Sockets 2).
-
also brauchste winsock2 und nicht 1.1
-
achso, okay, dann hab ich das falsch verstanden. Allerdings hilft mir das ja dann auch nicht weiter, wenn ich eh select() nehme. Also nochmal die Frage:
Kann ich den Wert von FD_SETSIZE nun einfach auf z.B. 4.096 erhöhen?
-
Selbst wenn das gehen würde das wäre doch total ineffizient. Jedes mal wenn select fertig ist müsstest du im worst case alle 4096 Sockets durchlaufen.
-
probiers doch einfach aus mit und ohne #define. wenn das prog nur bei der nicht-define variante abkackt, dann is alles ok.