Bild ständig aktualisieren

[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