Bild ständig aktualisieren

[michael]

Hi,

Ich habe eine Elektronik-Schaltung, die mir ständig Daten an den PC liefert. Diese werden von einem Java-Programm entgegengenommen, grafisch umgesetzt und (zurzeit) als JPG-Datei gespeichert. Nun möchte ich gerne aus dem Internet live auf dieses Bild zugreifen können. Besondere Herausforderung: Die Grafik wird 2-8 mal pro Sekunde aktualisiert, es entsteht also praktisch ein 'Film'. Und der soll möglichst sauber via Internet übertragen und angezeigt werden.

Am liebsten soll das ganze nur mit absoluten Standard-Technologien wie HTML und JavaScript funktionieren, auch Flash käme noch in Frage. Auf ein Java-Applet möchte ich verzichten.

Wie könnte man so etwas lösen?

Gruss

Michael

[Stefano Albrecht]

Servus Michael!

Besondere Herausforderung: Die Grafik wird 2-8 mal pro Sekunde aktualisiert, es entsteht also praktisch ein 'Film'. Und der soll möglichst sauber via Internet übertragen und angezeigt werden.

In diesem Fall solltest Du einen Stream via UDP zur Verfügung Stellen - vorzugsweise unmittelbar aus der Java-Applikation. Du kannst keinen Film machen, wenn die Bilder zuvor immer wieder in eine Datei gespeichert werden. Und um das Kriterium der "Langsamkeit" zu vervollsttändigen:
1.) Wir sprechen hier von einer Java-Applikation, welche die Bilder erstellt...
2.) Du willst die Angelegenheit per HTTP lösen. Dieses *Anwendungsprotokoll* verwendet jedoch das *Netzwerkprotokoll* TCP, und TCP ist durch den Three-Way-Handshake bekanntermaßen relativ langsam. Einen Stream wirst du hiermit nur mit sehr wenigen Benutzern erstellen können, die Sache mit der Datei mal außen vor gelassen.

Wie könnte man so etwas lösen?

Die Java-Applikation sollte das Bild über einen eigenen UDP-Stream zur Verfügung stellen. Wunderbar wäre es, wenn das Programm hierfür einen Object-Stream verwendet. Dann kannst Du die Images oder BufferedImages oder StoredImages serialisiert als Objekt senden. Diesen Dienst könnte dann ein Java-Applet nutzen, aber das möchtest Du ja nicht. Das Ganze hier genauer zu erklären würde den Thread jedoch sprengen, und nützliche Links fallen mir gerade hierzu nicht ein... Google?

Freundliche Grüße
Stefano Albrecht

[michael]

Hallo

In diesem Fall solltest Du einen Stream via UDP zur Verfügung Stellen - vorzugsweise unmittelbar aus der Java-Applikation. Du kannst keinen Film machen, wenn die Bilder zuvor immer wieder in eine Datei gespeichert werden. Und um das Kriterium der "Langsamkeit" zu vervollsttändigen:

1.) Wir sprechen hier von einer Java-Applikation, welche die Bilder erstellt...

Naja, _das_ mit Java=Langsam gehört wohl definitiv der Vergangenheit an. Auf jeden Fall in solch pauschalen Aussagen, ohne jegliche Kenntnis über die Funktionsweise des Programms zu haben.

2.) Du willst die Angelegenheit per HTTP lösen. Dieses *Anwendungsprotokoll* verwendet jedoch das *Netzwerkprotokoll* TCP, und TCP ist durch den Three-Way-Handshake bekanntermaßen relativ langsam. Einen Stream wirst du hiermit nur mit sehr wenigen Benutzern erstellen können, die Sache mit der Datei mal außen vor gelassen.

Es _ist_ auch ein sehr kleines Projekt. Zudem sind die Dateigrössen im einstelligen KB-Bereich.

Wie könnte man so etwas lösen?

Die Java-Applikation sollte das Bild über einen eigenen UDP-Stream zur Verfügung stellen. Wunderbar wäre es, wenn das Programm hierfür einen Object-Stream verwendet. Dann kannst Du die Images oder BufferedImages oder StoredImages serialisiert als Objekt senden. Diesen Dienst könnte dann ein Java-Applet nutzen, aber das möchtest Du ja nicht. Das Ganze hier genauer zu erklären würde den Thread jedoch sprengen, und nützliche Links fallen mir gerade hierzu nicht ein... Google?

Hört sich auf jeden Fall interessant an. Auf Applets möchte ich verzichten, da sie - im Gegensatz zur Sprache Java, die sich mittlerweile etabliert hat - meiner Meinung nach 'tot' sind. Insgesamt finde ich die Lösung aber doch relativ kompliziert und aufwändig. Aber mal sehen ;-)

Gruss

Michael

[Daniel Thoma]

Hallo michael,

Hört sich auf jeden Fall interessant an. Auf Applets möchte ich verzichten, da sie - im Gegensatz zur Sprache Java, die sich mittlerweile etabliert hat - meiner Meinung nach 'tot' sind.

Flash ist vermutlich deutlich verbreiterter auf Clients, aber Sun arbeitet auch fleißig daran, das zumindest etwas zu ändern. Ein Argument muss das aber so oder so nicht sein. Entscheidend ist, was deine Zielgruppe hat oder zu installieren bereit ist. Grundsätzlich geeignet wäre die Technologie in dem Fall.

Grüße

Daniel

[Daniel Thoma]

Hallo Stefano,

1.) Wir sprechen hier von einer Java-Applikation, welche die Bilder erstellt...

Es wird ja nicht gesagt, was die tut, aber 2-8 Bilder / Sekunde erzeugen und wegschreiben sollte erst mal gehen. (Kommt natürlich auf die Bilder an, aber Java sollte da dann auch nicht unbeding das Problem sein, jedenfalls ist die Aussage in dieser Pauschalität schwachsinn)

2.) Du willst die Angelegenheit per HTTP lösen. Dieses *Anwendungsprotokoll* verwendet jedoch das *Netzwerkprotokoll* TCP, und TCP ist durch den Three-Way-Handshake bekanntermaßen relativ langsam.

Das ist Bullshit. Der Handshake passiert beim Verbindungsauf- und -abbau. Ansonsten erreicht man mit TCP sehr guten Durchsatz weswegen die meisten Protokolle, die dazu verwendet werden, große Datenmengen zu übertragen, auf TCP basieren (HTTP, FTP, ...). UDP ist interessant, wenn man sehr kleine Datenmengen übertragen will (z.B. DNS Anfragen) oder man die Übertragungssicherung schon in einer höheren Protokollebene implementieren muss oder will um mehr Einfluss zu haben. Letzteres könnte evtl. für Streaming interessant sein, wenn man vermeiden will, dass verlorene Pakete nochmals geschickt werden o.ä.

Die Java-Applikation sollte das Bild über einen eigenen UDP-Stream zur Verfügung stellen. Wunderbar wäre es, wenn das Programm hierfür einen Object-Stream verwendet. Dann kannst Du die Images oder BufferedImages oder StoredImages serialisiert als Objekt senden.

Du willst also nicht eine Codierung für Video oder Bilddaten (mpeg, jpeg, ...) verwenden, sondern Du willst tatsächlich Java-Objekte serialisieren mit allem, was da so dran hängt? Und statt ein bewährtes Protokoll wie TCP zu verwenden, um diese Daten dann zu übertragen, willst Du das selber mit UDP implementieren?

Zur Frage selbst:
Eine optimale Lösung wäre vermutlich, direkt aus der Javaanwendung heraus einen Videostream zu erzeugen (mittels passender Bibliothek und evtl. Streamingserversoftware. Ich kenne mich da allerdings nicht aus). Diesen Stream könnte man dann direkt bereitstellen und/oder mit einem Flashplayer auf der Webseite darstellen.

Als Bastellösung könnte man vermutlich einfach immer die 100 aktuellsten Bilder o.ä. bereithalten und von einem Flashclient abrufen lassen. Der bekommt dann zum Bild immer die Information, wie lang er das anzeigen soll und wenn es noch keines gibt, wann er erneut nachfragen kann.
Zu groß sollten die Bilder allerdings nicht sein, sonst können die nicht mehr schnell genug übertragen und gerendert werden. Außerdem sollte man das natürlich möglichst über eine Verbindung abwickeln, wenn man HTTP verwendet, sollte man also darauf achten, dass das auch passiert.

Grüße

Daniel

[Stefano Albrecht]

Servus Daniel,

erstmal ganz locker mit dem ganzen Geflame von wegen Schwachsinn und Bullshit. Ich gehe das der Reihe nach durch.

1.) Wir sprechen hier von einer Java-Applikation, welche die Bilder erstellt...
Es wird ja nicht gesagt, was die tut, aber 2-8 Bilder / Sekunde erzeugen und wegschreiben sollte erst mal gehen.

Hast Du jemals intensiver mit Java gearbeitet? Vermutlich nicht. Ich nehme an, dass der Host für die finale Bildverarbeitung die JIMI-Bibliothek verwendet. Damit lassen sich die Images, oder die seltsamerweise langsameren BufferedImages (im Gegensatz zu String und BufferedString) in dem gewünschtem Format abspeichern. Während diese Bibliothek mittlerweile eine gewisse Reife in Bezug auf Sicherheit errungen hat, so kann man immer noch nicht von vergleichbarer Leistung zu entsprechenden C/C++-Anwendungen sprechen (Achtung: Leistung ist Arbeit durch Zeit, nicht Arbeit). Wieso? Lass uns auf den Punkt Sicherheit zurück kommen. JIMI prüft das Produkt rekursiv über Prüfsummen (CRC32). Stimmten die Prüfsumme vom Objektimage und Dateiimage überein, ist alles inordnung. Andernfalls wird eine tödliche Exception geworfen. Ignorieren? Vielleicht, es handelt sich immerhin um ein Video. Fazit für den kompletten Verlauf: Das Java-Programm erstellt ein Bild, das geht mit BufferedImage relativ fix. Aber moment.... neeeiiin! Was haben wir vergessen? Stimmt! JFrame! Will der Host anspruchsvollere Aktionen, beispielsweise pixelorintierte Manipulation vornehmen, so muss er das Image-Objekt zuvor über die Instanzmethode "createImage" von JFrame kopieren, und einem BufferedImage übergeben! Und wofür steht das "J" in JFrame? Genau, für die Java Foundation Classes (Swing)! Und das ist, mit aller Liebe zu java, eine verdammt langsame und zudem speicherfressende Angelegenheit! Dies jedoch nur nebenbei. Wenn das Bild schießlich erstellt wurde, muss JIMI das Ganze in eine Datei konventieren. Siehe oben, das kann dauern. Insgesamt ist das eine durchaus schaffbare Sache, auch, wenn es 5, 10, oder gar 20 Mal in der Sekunde gemacht werden soll. Aber dann soll noch ein Client per HTTP darauf zugreifen. Mhhhh schafft der das auch 8 mal in der Sekunde? Und was ist mit 100 Clients?

2.) Du willst die Angelegenheit per HTTP lösen. Dieses *Anwendungsprotokoll* verwendet jedoch das *Netzwerkprotokoll* TCP, und TCP ist durch den Three-Way-Handshake bekanntermaßen relativ langsam.
Das ist Bullshit.

Ahja. Gehen wir das mal ganz langsam durch. Hätte ich gewusst, dass das zu einer Erbsenzählerei wird, hätte ich den ganzen Roman schon zuvor verfassen können... Um es vorweg zu nehmen: Der Handshake ist bei Weitem nicht alles. Das hätte ich wohl vorher sagen sollen.

Der Handshake passiert beim Verbindungsauf- und -abbau.

In der Tat.

Ansonsten erreicht man mit TCP sehr guten Durchsatz weswegen die meisten Protokolle, die dazu verwendet werden, große Datenmengen zu übertragen, auf TCP basieren (HTTP, FTP, ...).

Wieso verwenden HTTP und FTP TCP?
Überlegung: Beide Protokolle senden oft sensible Daten (natürlich, es gibt auch SSL und die entsprechenden Implementationen wie HTTPS und SCPY, ich weiß...). Zumindest möchten beide Protokolle, dass ihre Datentransfers korrekt sind. HTTP u.a. wegen der korrekten Darstellung, FTP wegen der schlichtweg korrekten Datei (Stichwort "file is corrupt..."), was man ja mindestens verlangen kann. Kommen wir zu TCP. Dieses Protokoll bietet hierzu einige Meschanismen. Zunächst gibt es Sequenznummern, die versichern sollen, dass die Daten in korrekter Reihenfolge zusammengesetzt werden (... Sprung ...) Dann gibt es die CRC32-Prüfsummen, die versichern sollen, dass der Datentransfer die Integritäten erfüllt. Ob ICMP während dessen beim Clienten mitläuft, um Fehlerbehandlung vorzunehmen, sei außen vor gelassen. Insgesamt scheint TCP jedoch Einiges zu tun zu haben, bis die Daten gesendet oder erhalten sind, im Gegensatz zu UDP, bei dem diese Meschanismen fehlen. Bestimmt habe ich noch andere wichtige und zeitintensive Kriterien von TCP vergessen.

UDP ist interessant, wenn man sehr kleine Datenmengen übertragen will

Allerdings. Und Bildchen, die die Maße von 500 x 500 wohl nicht übertreffen, zudem vermutlich noch als JPG vorliegen, sind keine großen Datenmengen. Also haben wir ja einen Idealfall!

könnte evtl. für Streaming interessant sein, wenn man vermeiden will, dass verlorene Pakete nochmals geschickt werden o.ä.

Du sagst es!

Du willst also nicht eine Codierung für Video oder Bilddaten (mpeg, jpeg, ...) verwenden, sondern Du willst tatsächlich Java-Objekte serialisieren mit allem, was da so dran hängt? Und statt ein bewährtes Protokoll wie TCP zu verwenden, um diese Daten dann zu übertragen, willst Du das selber mit UDP implementieren?

Wahrscheinlich hast Du auch keine Erfahrung mit Serialisierung in Java. Attribute lassen sich als "transient" (etwa temporär) deklarieren. Methoden werden natürlich nicht serialisiert. In BufferedImage sind über 60% der Attribute als transient deklariert. Es werden nur das Array für die Bitweise Verarbeitung der Pixel (setRGB usw.) und einige Statusflags (z.B. Ladestatus, wieso auch immer...) mit gesendet. Insgesamt ist das eine wesentlich kleinere Datenmenge, als das ganze Bild zu senden. Ein Videostream bietet sich durchaus an! Nur habe ich keine Ahnung, wie ich in MPEG usw. konventiere! Und ich nehme an, dem Host geht es genauso.

Eine optimale Lösung wäre vermutlich, direkt aus der Javaanwendung heraus einen Videostream zu erzeugen (mittels passender Bibliothek und evtl. Streamingserversoftware. Ich kenne mich da allerdings nicht aus). Diesen Stream könnte man dann direkt bereitstellen und/oder mit einem Flashplayer auf der Webseite darstellen.

Ist prinzipiell nicht anderes, als mein Vorschlag. Für den Videostream würde ich gerne eine entsprechende Bibliothek sehen.

Zum Schluss noch mal zur "Pauschalität" von langsamen Java-Applikationen (mit Bezug auf die Antwort der Hosts). Mir ist sehrwohl bewusst, dass Java in vielen Bereichen immer schneller wird, allerdings nicht sämtlichen. Sun selbst schätzt den Geschwindigkeitsverlust im Vergleich zu "nativen" Compiliersprachen um bis zu 10% ein. Und das ist immer noch beträchtlich. Persönliche Erfahrungen sind zum Beispiel:
1.) Iterieren durch eine ArrayList mit 1.000.000 Einträgen ist etwa 15 % langsamer, als ein vergleichbares Konstrukt in C++, dass ich selbst erstellt habe (ebenfalls ArrayList getauft). Und dabei hätte das durchaus performanter sein können!
2.) Mein persönlicher Vergleich zu Javas ServerSocket + Socket (TCP-Sockets) und dem WinSock in C/C++ ergab, dass die nahezu identisch aufgebauten Java- und C++-Applikationen Geschwindigkeitsdifferenzen von bis zu 400 Millisekunden hatten (Java war langsamer)! Und das ist enorm!

usw...

Zu guter Letzt würde ich gerne einen halbwegs anspruchsvollen Videostream von Dir sehen, der tatsächlich TCP zur Übertragung verwendet. Und wenn Du das getan hast, dann bezeichne is das als "Bullshit" und "Schwachsinn", denn wieso werden Videos auf Datenintegrität und Sequenzreihenfolge geprüft? Werden etwa Passwörter über ein Video gesendet?

Hoffentlich habe ich in meinem ganzen Brainstorming nichts vergessen zu erwähnen... Ansonsten wird nachgeliefert ;~)

Freundliche Grüße
Stefano Albrecht

[Stefano Albrecht]

Ach, und was ich ganz vergessen habe:

Das ist Bullshit. Der [Three-Way-]Handshake passiert beim Verbindungsauf- und -abbau.

Da hast Du tatsächlich Bullshit geschrieben!
Der Three-Way-Handshake wird nur beim Verbindungsaufbau, nicht beim Abbau getätigt! So sieht ein Abbau aus:

Client > FIN
Server > ACK
Server > FIN
Client > ACK

also ein 2x2-Handshake, oder eben

Client/Server > RST

;~)

Freundliche Grüße
Stefano Albrecht

[Daniel Thoma]

Hallo Stefano,

Hast Du jemals intensiver mit Java gearbeitet?

Das habe ich sehr wohl.

Was haben wir vergessen? Stimmt! JFrame! Will der Host anspruchsvollere Aktionen, beispielsweise pixelorintierte Manipulation vornehmen, so muss er das Image-Objekt zuvor über die Instanzmethode "createImage" von JFrame kopieren, und einem BufferedImage übergeben!

Wieso sollte hier mit Swing rumbasteln? Ein BuffedImage hat eine Methode um ein Graphics2D Objekt zu beziehen und darin rumzumalen. Das kann ich dann mit javax.imageio.ImageIO.write(...) irgendwo hin schreiben.

Insgesamt ist das eine durchaus schaffbare Sache, auch, wenn es 5, 10, oder gar 20 Mal in der Sekunde gemacht werden soll. Aber dann soll noch ein Client per HTTP darauf zugreifen. Mhhhh schafft der das auch 8 mal in der Sekunde? Und was ist mit 100 Clients?

Nun, das stellt natürlich dann gewisse ansprüche an den Webserver. Über 100 Gleichzeitige verbindungen 8 Bilder/Sekunde rauszuschieben muss er packen. Die Bilder dürfen sicher nicht sehr groß sein, sind sie aber anscheinend auch nicht.

Der Handshake passiert beim Verbindungsauf- und -abbau.

Ok beim Abbau passiert ein Bisschen was anderes, wichtig ist, für die Übertragungsgeschwindigkeit ist es irrelevant.

Wieso verwenden HTTP und FTP TCP?

Zumindest möchten beide Protokolle, dass ihre Datentransfers korrekt sind.
Richtig, es sollen _alle_ Daten in der richtigen Reihenfolge ankommen. Mit sensiblen Daten hat das erst mal nichts mehr zu tun. Auch ein Bild oder ein serialisierte Java-Objekt kann man wegwerfen, wenn ein Paket fehlt und man muss die Reihenfolge kennen. Wenn man also UDP verwendet, muss man die Daten in einer Form übertragen, in der auch einfach mal ein Paket weg fallen kann.
Das ist bei Java-Objekten garantiert _nicht_ der Fall.

Insgesamt scheint TCP jedoch Einiges zu tun zu haben, bis die Daten gesendet oder erhalten sind, im Gegensatz zu UDP, bei dem diese Meschanismen fehlen.

Stimmt, aber sobald deine Daten nicht mehr in ein Paket passen, brauchst Du diese Mechanismen.
Allen gemeinsam dürfte sein, dass der Aufwand, der Betrieben wird, um Objekte zu serialisieren und zu deserialisieren größer ist.
UDP ist in dem Fall höchstens dann interessant, wenn man will, dass bei langsamen Verbindungen noch ein Teil der Daten ankommt. Mit diesem Teil der Daten muss man dann aber auch noch was vernünftiges machen können. Das zu erreichen bedarf einiges an Überlegung.

Allerdings. Und Bildchen, die die Maße von 500 x 500 wohl nicht übertreffen, zudem vermutlich noch als JPG vorliegen, sind keine großen Datenmengen.

Es liegt aber nicht als JPG vor, wenn Du Objekte serialisierst wie vorgeschlagen. Und selbst wenn Du es in UDP Pakete rein bekommst, entsteht dadurch höchstens dann ein vorteil, wenn die Verbindung zu langsam ist, um alles zu übertragen. Das ist aber nicht das, was Du gesagt hast. Deine Aussage war "TCP ist langsam weil 3-Wege-Handshake".

Wahrscheinlich hast Du auch keine Erfahrung mit Serialisierung in Java.

Zweite Überraschung: die habe ich auch.

In BufferedImage sind über 60% der Attribute als transient deklariert.

Interessante information. Nach einem Blick in den Quellcode sehe ich allerdings, dass gar nichts als transient deklariert ist.
Dafür hängen schon mal 4 weitere Objekte (ColorModel, WritableRaster, OffScreenImageSource und eine Hashtable) dran, die natürlich mit serialisiert werden. WritableRaster referenziert dann ein DataBuffer, der irgendwie die Bilddaten in einem Array speichert. transient ist da auch wieder nix. Außerdem hängen überall noch verschiedene, weitere Objekte dran. Ich hab' das jetzt nicht alles verfolgt.

Es werden nur das Array für die Bitweise Verarbeitung der Pixel

Das dürften 3 Byte / Pixel sein. Also alles andere als eine optimale codierung.

Ist prinzipiell nicht anderes, als mein Vorschlag. Für den Videostream würde ich gerne eine entsprechende Bibliothek sehen.

< http://java.sun.com/products/java-media/jmf/2.1.1/formats.html> erlaubt schon mal AVI zu erzeugen. Ich weiß nicht, wie gut das ist, aber da ist eben etwas experimentieren und recherchieren angesagt.

Zum Schluss noch mal zur "Pauschalität" von langsamen Java-Applikationen (mit Bezug auf die Antwort der Hosts). Mir ist sehrwohl bewusst, dass Java in vielen Bereichen immer schneller wird, allerdings nicht sämtlichen.

Meistens ist es das Wert. Das es Fälle gibt, in denen Java nicht geeignet ist, ist klar. Für sehr viele Anwendungen gilt das nicht, für diese wahrscheinlich auch nicht.

1.) Iterieren durch eine ArrayList mit 1.000.000 Einträgen ist etwa 15 % langsamer, als ein vergleichbares Konstrukt in C++, dass ich selbst erstellt habe (ebenfalls ArrayList getauft). Und dabei hätte das durchaus performanter sein können!
2.) Mein persönlicher Vergleich zu Javas ServerSocket + Socket (TCP-Sockets) und dem WinSock in C/C++ ergab, dass die nahezu identisch aufgebauten Java- und C++-Applikationen Geschwindigkeitsdifferenzen von bis zu 400 Millisekunden hatten (Java war langsamer)! Und das ist enorm!

Mag sein. Solcher Benchmarks sind aber immer mit vorsicht zu genießen, vor allem wenn man den Quelltext nicht gesehen hat.
Iterieren über eine ArrayList ist im wesentlichen Iterieren über einen Array. Das das deutlich langsamer in Java als in C++ ist, erscheint merkwürdig. Auch bei den Sockets ist das etwas merkwürdig. Die Java-API verwendet ja intern auch nix anderes.

wieso werden Videos auf Datenintegrität und Sequenzreihenfolge geprüft?

Weil der Videodecoder korrekte Daten in der richtigen Reihenfolge benötigt, wenn man keine spezielle Codierung verwendet. Ob Passwörter o.ä. sicherheitsrelevante Daten Übertragen werden, hat mit TCP nichts zu tun.

ARD scheint die Streams per HTTP zur verfügung zu stellen. Ich hab' das jetzt allerdings nicht auseinandergepfückt.

Grüße

Daniel

[Stefano Albrecht]

Servus Daniel ;~)

Wieso sollte hier mit Swing rumbasteln?

Fehler meinerseits. Ich arbeite überwiegend mit ImageProducern durch das crateImage(), das Produkt ist ein BufferedImage. Du hast Recht. Ich habe die Konstruktoren von BufferedImage völlig vergessen, und das, obwohl ich sie ebenfalls gelegentlich verwende.

Der Handshake passiert beim Verbindungsauf- und -abbau.
Ok beim Abbau passiert ein Bisschen was anderes, wichtig ist, für die Übertragungsgeschwindigkeit ist es irrelevant.

Du meintest sicher, dass es für die Übertragungsgeschwindigkeit *nicht* relevant ist.

Insgesamt scheint TCP jedoch Einiges zu tun zu haben, bis die Daten gesendet oder erhalten sind, im Gegensatz zu UDP, bei dem diese Meschanismen fehlen.
Stimmt, aber sobald deine Daten nicht mehr in ein Paket passen, brauchst Du diese Mechanismen.

Glaubst Du, ein solches Bildchen oder Objektchen übertrifft 65535 Bytes? Abgesehen davon braucht man dann zunächst mal die Sequenznummern. Datenintegrität "hat damit nichts mehr zu tun", wie Du so gerne sagst, denn sie ist, wenn vorhanden, auch auf geschlossene Packete anzuwenden, nicht erst auf verteilte.

Allen gemeinsam dürfte sein, dass der Aufwand, der Betrieben wird, um Objekte zu serialisieren und zu deserialisieren größer ist.
UDP ist in dem Fall höchstens dann interessant, wenn man will, dass bei langsamen Verbindungen noch ein Teil der Daten ankommt. Mit diesem Teil der Daten muss man dann aber auch noch was vernünftiges machen können. Das zu erreichen bedarf einiges an Überlegung.

Allerdings, aber das ist ja das Gute und Schöne daran ;~)

In BufferedImage sind über 60% der Attribute als transient deklariert.
Interessante information. Nach einem Blick in den Quellcode sehe ich allerdings, dass gar nichts als transient deklariert ist.

Zugegebenermaßen, die Angelegenheit habe ich selbst auch noch nicht überprüft. Die Aussage stammt von einem "Kollegen", der damit mal zu tun hatte. Insgesamt glaube ich jedoch nicht, dass er mich sinnlos belügt. Ich nehme an, das hat schon seine Wurzeln, vermutlich hat er das seinen Versuchen entnommen.

Das es Fälle gibt, in denen Java nicht geeignet ist, ist klar. Für sehr viele Anwendungen gilt das nicht, für diese wahrscheinlich auch nicht.

Das kann auch so stehen bleiben. Meine "Tests" haben mich nie von Java abgelenkt. Ich nutze es weiterhin für fast sämtliche Problemstellungen. Java ist exzellent.

Gerade eben habe ich, um unsere Gespräche sinnvoll zu ergänzen, eine kleine Recherche bezüglich der Videostreams unternommen. Rausgekommen ist Folgendes:

• Beispiel für Videostreaming über HTTP: Quick Time Videostreaming
• Beispiel für Videostreaming über UDP: RealTime Videostraming

Beide Artikel nennen als offensichtlichen Vorteil in Sachen HTTP, dass die Firewall ruhig bleibt. Quick Time bietet alternativ einen Stream via UDP, RealTime alternativ einen Stream via TCP an. Insgesamt stehen sich jedoch zwei ebenwürdige "Giganten" mit zwei konkurrierenden Methoden gegenüber.

Freundliche Grüße
Stefano Albrecht

[Stefano Albrecht]

RealTime

RealPlayer...

[wahsaga]

hi,

Ok beim Abbau passiert ein Bisschen was anderes, wichtig ist, für die Übertragungsgeschwindigkeit ist es irrelevant.

Du meintest sicher, dass es für die Übertragungsgeschwindigkeit *nicht* relevant ist.

Ja, dass etwas _nicht_ relevant ist, meint man gemeinhin, wenn man das Wort irrelevant benutzt :-)

gruß,
wahsaga

[Stefano Albrecht]

Servus wahsaga!

Ja, dass etwas _nicht_ relevant ist, meint man gemeinhin, wenn man das Wort irrelevant benutzt :-)

Da dachte ich, jemand hätte sich vertippt, dabei habe ich mich nur verlesen... Sorry!

Freundliche Grüße
Stefano Albrecht

[Daniel Thoma]

Hallo Stefano,

Glaubst Du, ein solches Bildchen oder Objektchen übertrifft 65535 Bytes?

Für ein jpeg-Bild reicht es in dem Fall wohl. Für das Objekt kann es auch nicht reichen. Der Code ist relativ kompliziert und ein Teil davon spielt sich in irgendwelchen sun.* Klassen ab, deren Code ich erst herunterladen müsste. Aber wenn tatsächlich 3 Bytes/Pixel gespeichert werden sind das bei 500x500px schon deutlich mehr. Möglich, dass das irgendwie geschickter gemacht ist, so klein wie JPG ist es aber nicht, schließlich muss es direkt manipulierbar sein.

Allerdings, aber das ist ja das Gute und Schöne daran ;~)

Das ist natürlich ein Argument, aber vermutlich nicht Ziel des OP ;)

Zugegebenermaßen, die Angelegenheit habe ich selbst auch noch nicht überprüft. Die Aussage stammt von einem "Kollegen", der damit mal zu tun hatte. Insgesamt glaube ich jedoch nicht, dass er mich sinnlos belügt. Ich nehme an, das hat schon seine Wurzeln, vermutlich hat er das seinen Versuchen entnommen.

Nun, es ist definitiv nicht so, jedenfalls nicht mehr.

Grüße

Daniel

[JürgenB]

Hallo michael,

Ich habe eine Elektronik-Schaltung, die mir ständig Daten an den PC liefert. ...

schon mal an eine professionelle Lösung gedacht? LabVIEW hat auch ein Web-Interface.

Gruß, Jürgen