# Socket: Sende-, Empfangstrategien



## Shiroi (30. Okt 2007)

Hallo ich habe da eine Frage,
und zwar möchte ich gerne über einen Socket größere Daten verschicken, aber es muss auch gleichzeitig eine stetige Client-Server Kommunikation vorhanden sein, um z.B. die Dateiübertragung abzubrechen.

Deshalb habe ich mir jetzt überlegt, was da die beste Lösung dafür ist.

Ich benütze einen Buffered(Output/Input)Stream und habe jetzt versucht 2 Sockets von einem Client zu dem gleichen Server aufzubauen. Ein Socket für die Kommunikation, der andere für die Dateiübertragung.
Nun habe ich aber das Gefühl, dass der zweite Socket den ersten irgendwie überschreibt und der Server meldet auch immer nur eine einkommende Socketverbindung.
Kann das sein? Dazu hatte ich leider nichts gefunden ob das funktioniert. Ich habe es einfach mal versucht.

Die andere kompliziertere Variante wäre, wenn das mit den 2 Sockets nicht funktioniert, alles über ein Socket zu verschicken, halt dann nur mit einem extra Packet Header, um zwischen Datenpacketen und Nachrichten zu unterscheiden.
Dort ist dann ja das Problem, den Header zum richtigen Zeitpunkt abzuschicken, da ja immer wieder automatisch ein flush im BufferedOutputStream kommt und der Header am Anfang stehen muss.
Man kann ja zum Glück die max. Größe des Buffers übergeben. Sendet er dann tatsächlich den Buffer nur dann, wenn die max. Anzahl an Bytes im Buffer erreicht wurde, oder hängt das noch von etwas anderem ab? (Außer wenn man selber einen flush macht) und was ist eigentlich der Standardwert?
Wenn das der fall wäre, dann kann ich ja berechnen, wann ich wieder einen Header anfügen muss.
Nagut mir fällt auch gerade auf, dass es relativ egal ist, wann der flush kommt. Ich kann auch einfach nach jeden x Bytes den Header anhängen und eine Längenangabe darin einfügen. Was wäre dann ein geschicktes x?

Kennt jemand noch evtl. eine bessere Sende/Empfang Strategie? Das ist für mich noch ziemliches Neuland.

Danke!


----------



## anfänger15 (30. Okt 2007)

hab jetzt nicht alles gelesen aber normalerweiße müßte das mit 2 sockets schon gehen die dürfen aber nicht beide den gleichen port haben also *2 verschiedene* ports benutzen dann müßte es gehen


----------



## Shiroi (30. Okt 2007)

Mh ja, aber dann muss ich ja auch 2 verschiedene ServerSockets verwalten und da man ja mehrere Clienten auf einen ServerSocket verbinden kann (oder?) wollte ich es auch nur mit einem versuchen.


----------



## DocRandom (30. Okt 2007)

Hi Shiroi!

Es geht auch nur mit einem Socket, jedoch mußt Du auf der Serverseite eine art Mesagequeue machen, wo Du dann unterscheidest zwischen, Datenstrom und Commands!

lg
DocRandom


----------



## anfänger15 (30. Okt 2007)

das kommt jetzt eben darauf an was für dich besser ist wenn du 2 sockets nimmst wird es eben wesentlich einfacher das ganze zu implementieren dafür ist es eben nicht sehr effizient, wenn du 1 socket nimmst was durchaus auch machbar ist wird es eben schwieriger(aufwändiger)das ganze zu implementieren, dafür ist es resourceschonender

deine entscheidung, möglich ist beides


----------



## Shiroi (30. Okt 2007)

ah ja, ich habe so eine Queue implementiert, aber mir ist da gerade ein grob fahrlässiger Fehler aufgefallen. Ich überschreibe mir selbst mein eigenen akzeptierten Socket...

Die andere Sache die mich leider an diesen 2 Sockets stört, ist die die asynchronität der beide Sende-Sende und Empfang-Empfang Vorgänge. Na ja, beides hat vor und Nachteile, aber vom Daten auswerten her, müssten die 2 seperaten Sockets schneller sein, da man bei den Datenpacketen keine Header interpretieren muss, bzw. nur einen einzigen.


----------

