recv: Was ist, wenn die Gegenseite nicht mehr da ist?

[hellseher]

klar, aber jetzt will er ja epoll benutzen...

[volkard]

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.

[Herr-Vorragend]

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?

[Herr-Vorragend]

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...

[c.rackwitz]

nimm blockende sockets und ein select(), poll(), epoll() und wie der muell sonst noch heisst

[rely]

funktioniert nur mit glück mit blocking sockets.

[c.rackwitz]

rely, ich nehme an, du hast fuer die meinung auch gruende, weil sie sonst wertlos ist?

[rely]

na ist doch ganz logisch. wenns irgendwo blockt dann müssen alle anderen clients warten bis die blockierung gelöst ist.

[c.rackwitz]

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.

[rely]

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.

[c.rackwitz]

hm... so hab ich das noch garnicht betrachtet... danke fuer die erleuchtung

[Herr-Vorragend]

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

[c.rackwitz]

herr... du solltest einfach die vorhandene literatur konsultieren und nicht so armselige fragen stellen.

[Herr-Vorragend]

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...

[c.rackwitz]

die man pages helfen.
http://www.freebsd.org/cgi/man.cgi
ist z.b. ein man page portal

[Herr-Vorragend]

ja da gibts ja aber nix zu epoll, das einzige was ich finden konnte war diese seite, die die ganze sache aber auch nicht viel besser erklärt:
http://www.die.net/doc/linux/man/man4/epoll.4.html

ich hab jetzt schon mal folgenden code(ausschnitt):

...
	counter = 0;

	while (1)
	{
		n = epoll_wait(ep, events, CLIENTS, -1);

		for (i=0; i<n; i++)
		{
			if (events[i].data.fd == acc)
			{
				clients = accept(acc, 0, 0);

				events->events = EPOLLIN;
				events->data.fd = client;

				epoll_ctl(ep, EPOLL_CTL_ADD, client, events);

				counter++;
			}
...

acc ist dabei ein socket im listen-modus.

nun möchte ich, dass der Socket, der bei accept angenommen wird, auch irgendwie mit dem Wert von counter identifiziert werden kann, d.h. irgendwo in der event struktur soll der wert von counter gespeichert werden, aber ich hab keine Ahnung wie das funktionieren soll.
Ich hab auch einfach mal testweise events->data.u32 = counter gemacht, aber dann kommen gar keine nachrichten mehr an...

MfG, Herr-Vorragend

[Herr-Vorragend]

Hm, ich hab festgestellt, dass der erste angenommene Socket die ID 6 hat, der zweite 7, der dritte 8 usw.

kann ich mich darauf verlassen, dass der Zähler mit 6 beginnt und dann einfach ein "anzahl_maximale_clients+6" großes Array erstellen?

[nein]

Wenn es irgendwo dokumentiert ist, ja. Sonst nein.

[Herr-Vorragend]

Ja weiß irgendjemand wie ich es sonst machen könnte? Ich muss eben jedem angenommenen Socket eine eindeutige ID geben, der erste bekommt 0, der zweite 1 usw., damit ich diese später einfach als Indizes für ein Array benutzen kann...

[Herr-Vorragend]

okay, ihr wollt also nicht mit mir reden ^^

kann ich denn zumindest davon ausgehen, dass die socket-ids hochgezählt werden?
Dann würde ich nämlich

index = socket_id - socket_id_des_ersten_angenommenen_sockets

setzen.

Mfg