Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Passende Programmiersprache für Client/Server Applikation gesucht
Warum sollte man sich etwas selber stricken und dafür wertvolle Zeit investieren, die man besser für die eigentliche Problemstellung verwendet, wenn es für Java bereits hervorragende Frameworks gibt, die u.a. asynchrone Messagequeues, Persistierung usw. unterstützen?
Das Thema Serialisierung hatte ich schon vor Tagen hier erwähnt, das interessiert aber niemanden, weil es hier um das Anwendungsprotokoll geht. TCP kennt keine Nachrichtengrenzen, der Empfänger muss deinen Kram am anderen Ende also korrekt dekodieren können, er erhält nämlich nur Bytesalat.
SheepShaver schrieb:
Warum sollte man sich etwas selber stricken und dafür wertvolle Zeit investieren, die man besser für die eigentliche Problemstellung verwendet, wenn es für Java bereits hervorragende Frameworks gibt, die u.a. asynchrone Messagequeues, Persistierung usw. unterstützen?
Das habe ich nicht gesagt! Ich sagte das die pauschale Aussage ein eigenes Anwendungsprotokoll zu schreiben Humbug wäre, nicht korrekt ist. Es hängt von diversen Faktoren ab. Wenn ich lediglich triviale Daten senden und empfangen muss, dann benötige ich nicht unbedingt zusätzlichen Balast hinsichtlich des Overhead, der durch Drittprotokolle und APIs, wie SOAP, generiert wird. Es kann auch sinnvoll sein selbst ein schmales, aber transparentes Protokoll zu schreiben über das die Firma vollständig die Kontrolle hat und welches flexibel angepasst werden kann.
In vielen Fällen ist es natürlich sinnvoll existierende Komponenten zu nutzen, aber pauschal lässt sich das nicht beantworten. Java ist eine Programmiersprache und kein Baukastensystem, wo ich für jeden Kleinkram eine fette Komponente einbinde.
Du hast schon grundsätzlich recht, dass eigene Protokolle Vorteile (insbesondere hinsichtlich Performance) haben können. Andererseits sind Sachen wie der ObjectStream,SOAP usw. gut getestet, brauchen weniger Entwicklungszeit und der Performanceunterschied dürfte in den meisten Fällen kaum messbar sein. Natürlich muss man das aber immer je nach Projekt abwägen.
Es ist im Übrigen aber tatsächlich Unsinn, hier weiter über ne Eigenentwicklung zu diskutieren, weil der Threadersteller explizit sagte, dass ihm vorgegeben wurde, ein bestehendes Protokoll zu benutzen. Daher bringt ihn das sicher nicht weiter
Also mit der Aussage zu der Performance würde ich so nicht mitgehen.
Die Zeiten, in denen Java ne Performance Krücke war sind vorbei. Also darüber brauchst Du dir keine Gedanken zu machen.
Daher würde meine Empfehlung auf Java lauten, da auch durch Sachen wie Beans etc, euer Projekt sich gut umsetzen ließe.
gut, wir werden jetzt sicher java verwenden. falls es etwas gibt (ich bezweifle es zwar), dass ich mit java nicht bewerkstelligen kann, kann ich noch immer mittels JNI C++ Code verwenden (:
Zu dem Protokoll. Vorgefertigte sind wahrscheinlich schneller implementiert, aber ich muss auch darauf achten ob diese Protokolle von Adobe Flex/AIR unterstützt werden oder ob es eine geeignete Bibliothek dafür gibt. Deswegen bin ich mir auch nicht sicher ob der ObjectOutput- und -inputStream funktionieren wird, da es in Flex andere Datentypen gibt. Hab da mal ein bisschen über Serealisierung nachgeforscht, und da gibt es ein paar Probleme mit den Datentypen, zum Beispiel ist ein float in Java mit einer Number in Flex etwa "gleichzusetzen".
Da werd ich wohl noch einiges testen müssen bis ich mich auf ein Protokoll (ob schon vorgefertigt oder nicht) festsetzten kann.
Nein, ich habe diese bildhafte Formulierung ganz bewußt gewählt, weil die Daten im TCP-Buffer liegen und in mehreren Read/Write Aktionen ausgelesen werden können. Wird UDP als Transportprotokoll vom Threadersteller verwendet, liegt überhaupt keine keine geordnete Datenfolge vor. UDP gibt keine Garantie, dass ein einmal gesendetes Paket ankommt oder das Pakete in der gleichen Reihenfolge ankommen, in der sie gesendet wurden!
