Wäre nur wenig Router freundlich. Und warum zwei Kanäle? Eine TCP Verbindung ist bidirektional…
[QUOTE=tuxedo]Und warum zwei Kanäle? Eine TCP Verbindung ist bidirektional…[/QUOTE]Weil bei 2 Kanälen diese verkrampften Socket-Timeouts und das Polling entfällt. Denke mal nicht, dass man über einen Port, auf welchem man grad’ lauscht, noch irgendetwas senden kann (BindException). Ausserdem wärs im Zweifelsfall eh’ 'ne UDP-Verbindung.
Edit: Ausserdem gibts nur halb offene und halb geschlossene Verbindungen. Das bedeutet ein Kanal kann entweder nur zum Senden oder nur zum Empfangen geöffnet werden. Damit ist TCP in dieser Hinsicht keineswegs bidirektional.
Edit2: Kann aber auch sein, das ich mich Irre.
Och, TCP gibt’s doch auch mit einem Selektor. Da hast du dann Non-Blocking-IO (was SIMON übrigens so macht). D.h. du wirst benachrichtigt wenn etwas ankommt.
Oder du benutzt gleich Asynchrones NIO. Bei ordentlich vielen Daten kitzelst du damit das letzte Quäntchen Performance raus. Wenn du’s richtig machst.
Aber für die Otto-Normal-Anwendung mit <1000 gleichzeitig aktiven (d.h. gleichezeitig Daten schickenden) Clients reicht das Standard Blocking-IO locker aus.
Denke mal nicht, dass man über einen Port, auf welchem man grad’ lauscht, noch irgendetwas senden kann (BindException).
Doch, das geht sehr wohl. Du kannst auf einer einzigen TCP-Verbindung sowohl senden als auch empfangen, GLEICHZEITIG. Damit ist TCP nicht nur bi-direktional, sondern auch noch Full-Duplex.
Edit: Ausserdem gibts nur halb offene und halb geschlossene Verbindungen. Das bedeutet ein Kanal kann entweder nur zum Senden oder nur zum Empfangen geöffnet werden. Damit ist TCP in dieser Hinsicht keineswegs bidirektional.
Wenn das technisch tatsächlich so sein sollte (was ich aktuell nicht glauben kann): In der Anwendung merkt man davon nix. Der TCP Stack moderner Betriebssysteme managed das so schnell, dass du das absolut nicht merkst.
Edit2: Kann aber auch sein, das ich mich Irre.
Bin jetzt zu faul das mit Beweisen zu untermauern, aber ja, ich glaube du irrst dich da. Zumindest auf oberster TCP-Stack-Ebene ist von einem Half-Duplex Verfahren innerhalb einer Socket-Verbindung nix zu sehen/spüren.
UDP mit Multi- oder Broadcast über einen DSL-Router hinweg: Kannst du schlichtweg knicken. Im lokalen Netz, ja. Aber über’s Internet für „normalsterbliche“ nicht zu machen.
[update]
Wg. Full-Duplex: http://www.tfh-wildau.de/sbruntha/Material/NM/VL_NETM_ip_protokolle.pdf → Seite 16, unten.
Transmission Control Protocol – Wikipedia → Abschnitt „Allgemeines“, gleich im ersten Satz.
[QUOTE=tuxedo]http://de.wikipedia.org/wiki/Transmission_Control_Protocol --> Abschnitt “Allgemeines”, gleich im ersten Satz.[/QUOTE]Und in dem Satz danach, gleich das, was ich meinte… 2 halbduplexe Verbindungen, weil Senden und Empfangen nicht gleichzeitig geht.
Und das ist das was ich gesagt hatte: Intern mag das vielleicht “halb-duplex” sein. Aber
- merkt man davon nix
- muss man sich nicht drum kümmern
- ist es auf “API Ebene” durch die Bank weg Full-Duplex
Du kannst TCP ja auch über AX.25 (PacketRadio). Da hast du ggf. auch nur Halb-Duplex. Aber an der API ändert das nix. DU kannst parallel zum Empfang von Daten auch gleichzeitig Daten senden. Was die unteren OSI Schichten treiben interessieren nicht wirklich.
Wo also hat man als Enwickler durch dem Umstand, dass TCP intern mit zwei Halb-Duplex-Verbindungen arbeitet, ein Nachsehen?!
Hey
hab nochmal ein bisschen google gequält
Habe follgendes gefunden was ich noch interessant finde:
https://github.com/terraframe/lipermi
Ist anscheinend ein FORK von lipeRMI (Hab ich noch nix mit gemacht)
jedenfalls würde dieses Framework asynchrone aufrufe unterstützen.
Bin mal am testen
mfg
RMI arbeitet afaik ebenfalls asynchron. SIMON ist sowieso durch und durch asynchron gehalten.
Hab mal kurz in den LipeRMI Fork reingeschaut… Puuh. Das ist ja schon ein klein wenig “pervers”. Man kann da den entfernten Methodenaufruf an sich schon asynchron absetzen und sich über einen extra Handler über den Ausgang des Aufrufs informieren lassen.
Persönlich finde ich das “von hinten mit Faust durch die Brust in’s Auge” implementiert. Wenn man sehr low-level programmieren will, okay. Aber der große Vorteil von RPC ist doch, dass man sich nicht um das “darunter” kümmern muss und einfach Netzwerkunabhängig entwickelt, eben so, als wäre es eine StandAlone Anwendung.
Und wenn ich in einer StandAlone Anwendung eine Methode asynchron aufrufen möchte, dann packe ich das in einen Thread. Das ist nicht kompliziert und das kennt man für gewöhnlich auch. Der Vorteil: Man ist unabhängig von der darunterliegenden Technik. Man kann damit von RMI zu SIMON und/oder umgekehrt wechseln.
Wenn man sich hier mal auf diesen LipeRMI Fork eingeschossen hat, dann hat man, wenn man sich umentscheidet, viel Refactoring vor sich. Oder aber man bastelt wieder eine Abstraktionsschicht. Aber dann kann man auch gleich RMI oder SIMON nehmen. Da braucht man keine separate Abstraktionsschicht.
Unter’m Strich: Ich seh aktuell den Sinn für dieses Feature in LipeRMI nicht. Aber vielleicht bin ich nur noch nicht auf das notwendige Szenario gestoßen…
[update]
Und wenn man wirklich so ein Feature braucht, dann kann man sich das auch recht einfach selbst basteln. Dann kann man das auf jedes x-beliebige RPC Framework aufsetzen ohne sich festzulegen.