Suche Konzept: Gleichzeitige TCP Datentransfers

[Zacherl]

Hey,

ich möchte ein Programm schreiben, welches z.B. 5 Dateien gleichzeitig an einen Empfänger senden kann. Hierbei möchte ich auch nur ein Socket verwenden. Ich habe mir überlegt, dass ich in jedem meiner Sende Threads die Daten erstmal in Pakete aufteile und dann nacheinander sende.

Normalerweise habe ich die Größe der Daten vorweggesendet und dann beim Empfänger solange gewartet, bis alle Daten vollständig sind.

Bei den Multi Threaded Transfers allerdings habe ich ja zusätzlich das Problem, dass ich die einzelnen Datenblöcke beim Empfang richtig zuordnen können muss. Ich hatte überlegt auf Seiten des Senders eine ID einzuführen, die bei jedem Transfer um 1 erhöht wird und die zusätzlich zur Paketgröße jedem Paket als Header vorweggeschickt wird. Das erste Paket würde dann die Größe der Gesamtdaten beinhalten, woraufhin dann nach beschriebenem Muster die Datenpakete folgen würden. Durch die IDs wären die Pakete beim Empfänger ja eindeutig zuzuordnen.
Die Sende Threads würden sich dann selbstständig nach dem Senden eines Paketes anhalten und den nächsten Thread starten, bzw. das könnte man sicher auch über CriticalSections einfacher regeln oder?

Hat jemand vielleich ein einfacheres oder besseres Konzept?

Viele Grüße
Zacherl

[mkinzler]

Ja. Die Daten nacheinander senden

[Zacherl]

Zitat von mkinzler:

Ja. Die Daten nacheinander senden

Danke für diese konstruktive Antwort

[SirThornberry]

Da es hier ja um das Konzept geht wäre es interessant zu wissen warum nur ein Socket verwendet werden soll.
Denn wenn alles über einen Soll muss eine zusätzliche Information gesendet werden, und zwar welche Datei es ist. Und ich vermute das während 2 Dateien übertragen werden plötzlich eine dritte dazu kommen können soll?! Wenn dem so ist müsste auch die Info jedesmal mit gesendet werden ob es Daten einer Datei sind oder ob es die Bekanntgabe einer neuen Datei ist die hinzu kommen soll.

[mkinzler]

Deshalb wäre es meiner Meinung besser die Daten per FIFO zu senden.

[SirThornberry]

@mkinzler: Im ersten Moment dachte ich das auch. Im zweiten Moment habe ich an die gängigen Browser und Messanger Clients gedacht. Da wird überall gleichzeitig hoch- und runtergeladen. Und ich würde schon komisch schauen wenn ich mehrere Downloads habe und der zweite erst startet nachdem der erste abgeschlossen ist.

[mkinzler]

Diese verwenden aber verschiedene Sockets und könne sich dann auf den Mechanismus von TCP verlassen. So muss er sich selber darum kümmern

[Zacherl]

Das Problem ist dass meine Empfängeranwendung bei der ein Server Socket läuft sehr sehr viele Transfers gleichzeitig empfangen muss. Dabei von verschiedenen PC multiple Sockets zu öffnen, würde die Kapazität des Empfängers schnell ausreitzen. (erstmal die Sockets und für jedes Socket mindestens einen Empfangs Thread, da ich non-blocking arbeite)

Ich denke nochmal drüber nach und teste das ganze erstmal mit Multi Sockets. Vielleicht reichen die Ressourcen ja aus ..

[Astat]

Zitat von Zacherl:

Das Problem ist dass ... sehr sehr viele Transfers gleichzeitig empfangen muss. ... würde die Kapazität des Empfängers schnell ausreitzen. (erstmal die Sockets und für jedes Socket mindestens einen Empfangs Thread, da ich non-blocking arbeite)

Hallo Zacherl, für Verbindungs orientierte Hochlast Server Anwendungen, wird normalerweise folgendes Konzept verwendet.

1. Ein Socket Acceptor Thread speichert alle eingehenden Client Verbindungen in einem Ringbuffer.
2. Diese Client Verbindungen (Ringbuffer) werden von einer einstellbaren Anzahl von WorkerThreads (~8 THreads per CPU) abgearbeitet.

Unter Windows ist TcpNumConnections defaultmäßig auf 16777214 (16 Millionen) Gleichzeitiger Connections ausgelegt.

Bei Verwendung von Winsock 2.0 ist ein ähnliches Konzept verfügbar, jedoch mit wesentlich performanteren IOCP's

Solltest Du bei einem derartigen Konzept Resourcen bzw. performance Probleme bekommen, sehe ich nur noch Die möglichkeit
auf ein verbindungsloses Protokoll (UDP) umzusteigen.

lg. Astat