Kommunikation von Java-Server mit C#-Client
lima-city → Forum → Programmiersprachen → Java
abfragen
antworten
bereich
byte
datei
gewisse parameter
hauptgrund
kommunikation
kommunizieren
laufzeit
plattform
programm
protokoll
rolle
server
sprache
stolperfallen
teil
ursache
verteilen
-
Hallo zusammen,
ich bin seit einiger Zeit mit der Entwicklung eines Client-/Serversystems beschäftigt. Der Server ist, auf einem Linuxsystem laufend, in Java geschrieben und das soll auch so bleiben. Der Client war dies ursprünglich auch, aber da sich herausgestellt hat, dass ca. 30% aller User Probleme mit dem Ausführen einer einzigen JAR haben (man kennt das, sie entpacken sie mit WinRAR und wundern sich warum das nicht funktioniert und ähnliche Geistesblitze) , soll parallel eine baugleiche Version in C# bereitgestellt werden, um mit einer wohlbekannten .exe aufwarten zu können. Das ist nicht der einzige Grund, darum geht es aber auch nicht. Letztendlich geht es mir um die Kommunikation zwischen diesen beiden ungleichen Partnern. Die synchron Java Version kommuniziert zwar auf der Bytestreamebene und verwendet keine Serialisierung, dennoch frage ich mich, inwiefern die JVM da eine Rolle spielt und was beachtet werden muss, wenn nun der C#-Client mit dem Java-Server kommunizieren soll. Es wäre ja gerade zu schön um wahr zu sein, wenn das ohne Stolperfallen funktionieren würde. Wie also bringt man die C# TCP Sockets zur Kooperation mit den von der JVM so schön gekapselten Bytestreams.
p.s. Ich war mir nicht sicher ob ich es eher in den Java Bereich oder den .NET Bereich schreiben soll :D -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Programme kommunizieren immer über bestimmte Protokolle. Finde zunächst heraus, welches Protokoll der Server spricht und dann wirst du eventuell etwas auf der .NET-Plattform finden, was damit umgehen kann.
Und solange uns hier im Forum dieses Protokoll nicht bekannt ist, können wir dir nicht weiterhelfen.
Wobei es jetzt ein unnötiger Aufwand wäre das ganze nochmal in C# nachzuprogrammieren, wenn du schon eine fertige Java-Version hast. Du solltest eher mal schauen, wie man das Java-Programm so verteilen kann, dass jeder damit klarkommt. Notfalls zipst du die Jar-Datei einfach nochmal und packst einen (exe-basierten) Launcher für die Jar-Datei mit rein. -
An den .exe-Loader hätte ich jetzt auch gedacht...
TCP-Sockets sind übrigens überall gleich, also kannst du problemlos den Client in C# und den Server in Java haben. Wichtig ist nur, dass beide “die selbe Sprache sprechen“, also das gleiche Protokoll verwenden. -
Wenn man ganz entfernt mal draufschaut, und die 7 ISO/OSI Schichten betrachtet, dann stellt man schnell fest, wie schon gesagt wurde, dass die Sprache der Client und Serverside total unerheblich sind. Die JVM macht auch nichts anderes als die Daten an das Betriebssytsem zu geben, welche alles verwaltet. Und da das alles einem Standard folgt, spielt es keine Rolle. Wäre auch schlimm, wenn man den Ethernet-, TCP- und IP-Rahmen jedesmal selbst wieder zusammenstricken müsste 0.0
Für dich ist wichtig, ob du ein Standardiriertes Protokoll nimmst, oder ob du ein eigenes definierst. Wenn du ein "ACTION1" vom Client zum Server schickst, und dieser dann "ACTION1" liest, dann sollte der Server auch wissen, was er damit anfangen soll. Ich selbst nutze zur erstellung von Protokollen immer State-Event Matrizen, weil diese relativ einfach sind, aber im Internet findet sich dafür nichts so hilfreiches. Vielleicht sollt ich da selbst mal was zu verfassen. Vielleicht kennst du es ja aber auch so schon.
Fazit: Du bist total unabhängig von den genutzten Sprachen, du musst nur eine eigene Kommunikationssprache, bzw Verständigung zwischen den beiden Seiten aufbauen.
Liebe Grüße -
Danke schon mal für die Antworten soweit.
Also der Hauptgrund für die Portierung zu .NET ist auch nicht, dass einige mit der Java Version nicht klar kommen, denn dann würde wie bereits gesagt wurde eine exe zum Starten der Jar Datei genügen. Der Hauptgrund ist, dass der Client einige WMI-Abfragen durchführt und das ist unter Java gelinde gesagt etwas eingeschränkt. Im Moment funktioniert das über zur Laufzeit temporär erzeugte VB Scripts. Was mir dabei jedoch unerklärlich ist: Sind für die JVM gewisse Parameter gesetzt oder ist die PATH-Variable nicht korrekt gesetzt, läuft das Skript zwar, aber alle Abfragen geben leere Strings zurück. Das passiert aber auch so zuweilen, ohne dass ich bisher eine Ursache dafür finden konnte.
Das Protokoll ist TCP ich hatte vergessen das für den Java Teil zu erwähnen, aber was mich skeptisch werden ließ ist, dass ich in Java nur 2 Zeilen brauche (Konstruktion des Sockets und Öffnen des Streams) um bereit zum Lesen zu sein, während das unter .NET etwas komplizierter anmutet, daher hatte ich vermutet, dass die JVM da noch irgendeinen Teil der Arbeit übernimmt, den man dann auf Clientseite irgendwie beachten müsste. Was ich nun aus den Antworten herauslese ist, dass wenn ich vom Client ein Byte[] zum Server schicke, dann kann er ganz einfach dieses Byte[] über den InputStream des Sockets auch wieder einlesen.
@ggamee Nach Literatur zum ordentlichen Entwurf eines eigenen Protokolls suche ich schon seit ich mit der Netzwerkprogrammierung angefangen habe, also da wäre ich über jeden Fingerzeig erfreut :) . -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
