IO completion ports / senden an mehrere Clients
-
Hallo,
ich bastle an einem server, der die sende/empfang events über io completion ports erhält. wenn der server nachrichten an mehrere clients speichert, halte ich den puffer sowie die sockets im speicher, bis alle sendevorgänge abgeschlossen sind.
sollte nun aber der eine oder andere socket durch irgendein problem für die completion zu lange brauchen, dann würden sich die puffer stauen und benötigen immer mehr speicher.
es ist mir egal ob die daten nun beim client ankommen oder nicht, ich möchte nur sicher sein, dass der send vorgang nicht länger als eine bestimmte zeit dauert, damit ich die sendepuffer nicht zu lange im speicher halten muss. lt. msdn darf ich den puffer nicht benutzen solange der sendevorgang nicht abgeschlossen ist.
lg
-
Danke dafür, dass du uns über Details deines Projekts aufgeklärt hast :xmas2:
-
fmgls schrieb:
Danke dafür, dass du uns über Details deines Projekts aufgeklärt hast :xmas2:
ich suche eher danach wie sowas üblicherweise gehandhabt wird.
der server hat etwa 1000 clients. im prinzip ist die funktionsweise gleich eines chat servers.
lg
-
Sende halt nicht wild drauf los sondern mach ein Protokoll, bei dem erst eine completion kommen muss, bis die nächste msg gesendet wird. Kannst ja mit versch. message ids versch. "channel" aufbauen.
-
Hi schrieb:
Sende halt nicht wild drauf los sondern mach ein Protokoll, bei dem erst eine completion kommen muss, bis die nächste msg gesendet wird. Kannst ja mit versch. message ids versch. "channel" aufbauen.
ich habe es etwas umständlich erklärt. ich warte doch auf die completion.
ich habe eine queue für die zu sendenden nachrichten.ein beispiel.
ich sende eine nachricht an 10 clients.die nachricht und die sockets werden in einem puffer gespeichert.
danach rufe ich für jeden socket WSASend auf. wenn ich von allen die completion erhalten habe, lösche ich den puffer.falls inzwischen eine neue nachricht gesendet werden soll, kommt die in die queue.
üblicherweise ist der transfer sehr schnell abgeschlossen. sollte aber ein fehler auftreten bei dem der vorgang etwas dauert, dann stauen sich schlimmstenfalls die puffer in der queue.
-
10 buffer sind ja kein Problem. Und bevor die nächsten rausgehauen werden, wird auf die completions der 10 gewartet. Wo staut sich dann was?
-
Hi schrieb:
10 buffer sind ja kein Problem. Und bevor die nächsten rausgehauen werden, wird auf die completions der 10 gewartet. Wo staut sich dann was?
Es ist nur ein Datenpuffer für die 10 clients (die Nachricht ist ja für alle diesselbe)
Wenn jetzt ein Thread beispielsweise fortlaufend Nachrichten generiert, kommen die in die queue. Diese Puffer stauen sich meinte ich., falls die Nachrichten nicht schnell genug gesendet werden können.
-
?!
megatron schrieb:
Es ist nur ein Datenpuffer für die 10 clients (die Nachricht ist ja für alle diesselbe)
Für jeden deiner sends ein eigener buffer
megatron schrieb:
Wenn jetzt ein Thread beispielsweise fortlaufend Nachrichten generiert, kommen die in die queue. Diese Puffer stauen sich meinte ich., falls die Nachrichten nicht schnell genug gesendet werden können.
Dann muss der Thread eben, wie schon gesagt, zuerst warten, bis seine vorherige msg completed wurde
-
Hi schrieb:
?!
megatron schrieb:
Es ist nur ein Datenpuffer für die 10 clients (die Nachricht ist ja für alle diesselbe)
Für jeden deiner sends ein eigener buffer
megatron schrieb:
Wenn jetzt ein Thread beispielsweise fortlaufend Nachrichten generiert, kommen die in die queue. Diese Puffer stauen sich meinte ich., falls die Nachrichten nicht schnell genug gesendet werden können.
Dann muss der Thread eben, wie schon gesagt, zuerst warten, bis seine vorherige msg completed wurde
Es reicht ein puffer, wenn ich für jeden socket eine referenz darauf habe.
Der thread wartet auch solange, aber die daten gibts so oder so, und die muss ich zwischenspeichern, und der buffer wird mir zu voll, falls es eben probleme mit auch nur einem socket gibt.