Speicher voll: Server-Client-Anwendung (UDP)

UDP-Multicast:
Naja, ganz so einfach ist das nicht. Meine Versuche mit Multicast sind gescheitert. Ich nehme mal an, dass unsere IT da irgendwas blockiert. Aber ich möchte vermeiden, unsere IT-Leute mit ins Boot zu holen, weil die eh nix selbst dürfen und gleich bei der Konzernmutter auf der Matte stehen müssen, um sich temporäre Berechtigungen zu besorgen. Daher merkt sich mein Server die Clients, die sich bei ihm "anmelden" in einem simplen Array mit Client-IP und Client-Port. Die Senderoutine wird per Message-Queue angestoßen und schickt anhand der Nachricht in der Q Daten an Client xy. Bei max 5 Clients und lediglich einem Update pro Minute (1 Paket mit wenigen Bytes) ist das aber halb so wild.
Letztendlich dürfte sich also nicht soviel ändern, wenn ich das auf TCP umstricke, weil die Senderoutine dann eben einfach auf TCP sendet und nicht mehr auf UDP. Allerdings muss ich mich noch mit den Unterschieden im Detail auseinandersetzen. Zum Beispiel inwiefern ich TCP-Connections in einem Array festhalten kann/muss oder dergleichen...

Fehlernummer:
Das kann ich dir ehrlich gesagt nicht sagen. Ich teste die "verteilte" Anwendung derzeit quasi "unverteilt". Ich starte also an meinem PC gleichzeitig Server und Client und schicke mir selbst munter Nachrichten ^^ Zwischendurch teste ich das allerdings mit nem Kollegen im Büro. Eine Fehlernummer hatte ich gar nicht. Es trat nur das Phänomen auf, wenn ich vom Client aus eine Dateninitialisierung angestoßen habe ("Gib mir alles"), kam zwar soweit alles rüber, aber irgendwann beim zweiten, dritten, vierten Klicken (auch nach längerer Pause) kam plötzlich eine Fehlerbox "Speicher voll". Ein Blick in den Taskmanager zeigte dann, dass der Speicherbedarf nach einem Senden um schlanke 200-300 MB hoch ging. Ich vermute mal stark, dass das auch oder gar zum Großteil mit meiner alten Decodierung zu tun hatte und LV mir den Speicher mit Dutzenden oder gar Hunderten Kopien der Daten zugemüllt hat. Rein rechnerisch wären die 100 Pakete (vor Byte-Konvertierung) zu jeweils 8 KB nämlich gerade mal 800 KB und keine 200-300 MB. Wenn da aber munter Kopien erzeugt werden, die der Garbage-Collector dann nicht mehr aufräumt, ist der Speicher halt irgendwann voll. Ich erhoffe mir aber durch die schlauere Codierung nun auch eine schlauere Decodierung und bin das Problem dann hoffentlich los

Ende-Paket:
Bisher hab ich im Startpaket einfach die Anzahl der Pakete (neben t0, dt, Anzahl Kanäle, etc) mit übergeben. Sogesehen wüsste der Empfänger also wieviele Pakete er zu erwarten hat. Wenn ein Datenpaket sonst durch irgendwelche Netzwerk-Engpässe nen Tick später kommt als das Ende-Paket ist im wahrsten Sinne des Wortes Ende im Gelände. Wobei ich mir nicht sicher bin inwiefern TCP da jetzt sofort Alarm schlagen würde (von wegen "Paketsicherheit" und so).

Oha, du liegst im Krankenhaus? Na dann mal gute Besserung!