Klassendesign: Blockierender Constructor?

[Zacherl]

Zitat von Namenloser:

Also eigentlich ist das Paradigma bei blockierenden Sockets ja, dass man immer abwechselnd liest und schreibt. Deswegen ist mir nicht so ganz klar, warum du im Konstruktor bereits anfängst zu lesen (und einen extra Thread für das Senden erzeugst). Denn es hängt ja vom konkreten Protokoll ab, ob zuerst gelesen oder zuerst geschrieben werden muss. Soll IOHandler ein Platzhalter für die Implementierung des Protokolls sein, oder ist es eine Zwischenschicht zwischen Socket und Protokollimplementierung?

Der IO-Handler ist im Grunde ein (De-)Multiplexer, mit dem ich mehrere Streams / Pakete über ein einzelnes Socket tunnele. Es soll aber möglich sein Daten gleichzeitig zu senden und zu empfangen. Aus diesem Grund habe ich einen Thread, der nur pollt und einen weiteren Thread, der sich um das gechunkte Versenden der ausgehenden Daten kümmert. Das klassische Request-Response Prinzip kann ich hier nicht ohne Weiteres anwenden.

Falls du bessere Ideen zur Umsetzung hast, gerne immer her damit

Konkret möchte ich halt mehrere simultane (unterschiedlich priorisierte) Übertragungen über ein einzelnes Socket realisieren, wobei sowohl Client, als auch Server auf Benutzerinteraktion hin eigenständig Datenübertragungen beginnen können. Die Kummunikation folgt also nicht wirklich einem fest definierten linearen Verlauf.

Zitat von Namenloser:

[OT]Übrigens, weil ich gerade sehe, dass du auch Interfaces für die Sockets verwendest: Es ist schockierend, wie viel Overhead die Referenzzählung bei Interfaces verursacht ...[/OT]

Danke für den Hinweis, da werde ich mal drauf achten.