RMI RPC "not suitable for streams and.."

H

HugoW

Gast
Hallo Leute!

Heute habe ich gelesen, dass RPC "not suitable for multimedia streams or bulk data transfer" sei.
Warum genau ist das so?
Ich habe jetzt zwar schon einiges über RPC gelesen, aber so richtig einleuchten will mir die Aussage noch nicht.

Herzlichen Dank,
Hugo
 
T

tuxedo

Gast
RPC erfordert meist einiges an Reflection + Serialisierungs + Protokolloverhead.

Im Klartext:
RPC Techniken sind meist so abstrakt gehalten, dass man recht weit entfernt ist von "rohem Datentransfer". Man kann mit RPC recht einfach eine "entfernte Methode" aufrufen. Dazu wird ein entsprechendes Protokoll das hierfür "optimiert" ist eingesetzt. Die Daten werden im Protokoll-Layer dann meist serialisiert und deserialisiert (Methodenaufrufe haben ja meist irgendwelche Objekte als Argument).

Zumindest im Fall von RMI sollte man es sich zweimal überlegen ob man einen Multimedia-Stream über eine RMI Verbindung quält.

Wenn man nen Audio oder Videostream oder gar eien Datei überträgt ist es besser, wenn man hierfür ein geeignetes Protokoll wählt das für den jeweiligen Einsatzzweck passt und optimiert ist. Serialisierung fällt hier dann meist komplett weg (zumindest bei Audio und Video liegen ja schon irgendwelche byte[] Pakete vor und keine "Objekte").

- Alex
 

Murray

Top Contributor
RPC (egal mit welcher konkreten Protokollimplementierung) lebt ja eigentlich davon, dass man das so verwendet wie einen lokalen Funktionsaufruf: alle Parameter werden vollständig bereitgestellt, dann wird die Funktion aufgerufen, woraufhin dann das Ergebnis vollständig vorliegt.
Streaming ist ja etwas ganz anders: hier stellt die eine Seite laufend Daten bereit, die andere Seite holt ständig etwas ab - und zwar in der Regel bereits, bevor die sendende Seite alle Daten geschickt hat (gerade bei Live-Stream ist das offensichtlich, denn das ist es mit dem Ende natürlich schwierig...).
Wenn man also Streaming per RPC machen wollte, dann müsste man doch wieder "oberhalb" von RPC ein eigenes Protokoll erfinden, über das der Datenstrom in diskrete Chunks zerlegt und auf der Empfängerseite wieder zusammengebaut wird.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
M Verständnisfrage zu den Streams Netzwerkprogrammierung 7
J Threads & Streams Netzwerkprogrammierung 9
N Paket-Analysieren Byte-Streams Netzwerkprogrammierung 12
C Socket Cipher Streams Netzwerkprogrammierung 6
E Verfügbarkeit von Daten in Streams Netzwerkprogrammierung 4
V HTTP Streams setzen Netzwerkprogrammierung 10
N Socket Fehler bei Streams Netzwerkprogrammierung 2
1 SSH-Kommunikation - Ende eines Streams nicht erkenntlich Netzwerkprogrammierung 2
D Socket Streams schliessen .. Exception gewollt? Netzwerkprogrammierung 4
B Server mit meheren Streams/Aufgaben? Netzwerkprogrammierung 9
T HTTP Encoding von Http-Streams Netzwerkprogrammierung 2
L mehrere Streams über einen Socket? Netzwerkprogrammierung 8
V Mehrere Streams durch einen Stream senden Netzwerkprogrammierung 14
M Streams verwenden Netzwerkprogrammierung 3
A Streams per RMI übergeben Netzwerkprogrammierung 6
P problem beim schließen eines Streams Netzwerkprogrammierung 6
K Selbe Streams mehrfach nutzen (zusätl. Thread) Netzwerkprogrammierung 6
J while-Schleife / Abbruchbed. beim Einlesen eines Streams Netzwerkprogrammierung 4
J Länge eines Streams Netzwerkprogrammierung 4
M Streams Bündeln Netzwerkprogrammierung 10
P Probleme mit Input- / Output-Streams Netzwerkprogrammierung 2
M Ende des Streams ohne Schließen/Checksumme mitsenden Netzwerkprogrammierung 2
M Probleme beim Abfangen von Streams Netzwerkprogrammierung 5
8 Socket Streams nur mit Byte? Netzwerkprogrammierung 2
E frage zu streams Netzwerkprogrammierung 2
F ResultSet in Streams Netzwerkprogrammierung 8
C IRC CHAT auslesen -> Sockets/input und output Streams Netzwerkprogrammierung 9

Ähnliche Java Themen


Oben