[C#] Schnittstelle für Java

C

Computerfreak90

Mitglied
Hallo,
ich suche eine Schnittstelle für C#, mit der ich in der Programmiersprache Java (Android) Daten aus dem C# Programm abfragen und funktionen aus C# aufrufen kann.
Dieses soll über das Netzwerk funktionieren, trotzdem will ich keine TCp Conection machen oder etwas vergleichbares.
Gibt es da irgendeine möglichkeit mein vorhaben zu realisieren?
Vielen Dank im voraus
 
Eigentlich nicht, soweit ich weiß. Um allgemein Daten zwischen 2 Anwendungen auszutauschen werden Sockets oder eine SharedFile benötigt (zumindest was Java und C# betrifft, c++ & co weiß ich nicht, aber warscheinlich auch). Was willst du denn genau machen? Vielleicht kann hier jemand dir helfen, wenn man weiß, was du grob vorhast.

mfg
JustShinigami
 
Hi

Pipes, gemeinsamer Speicherbereich etc. kann man schon noch nennen,
aber da Computerfreak ja etwas Netzwerkbasiertes will...
Netzwerkbasiert ohne TCP-Connection :suspekt:
UDP? :D
Tcp bzw. irgendwas darauf Aufbauendes wäre das Sinnvollste.
 
hi,
Danke für die Antworten.
Also etwas Netzwerkbasietes sollte es schon sein.
Ich habe eine Software in C#, die ich nachher über Java (genauer über mein Android Handy), über das lokale Netz (WLAN) steuern kann. Ich sollte funktionen ansteuern können und Daten hin und hersenden. In Java ist das mit der TCP verbindung meiner meinung nach nicht so leich zu realisieren aber anscheinend geht das nicht anders.
Nachdem ich eure Beiträge gelesen habe, bin ich zu folgendem Ergebnis gekommen:
Also ich werde eine TCP oder UDP verbindung zwischen beiden Programmen aufbauen und dann darüber Daten schicken.
Mein Problem ist nur, dass ich nicht weiss, wie ich die Daten am besten verschicken kann.
Ich hatte an irgend ein format wie XMO oder Json gedacht aber gibt es da noch alternativen?
Bitte um Antwort
Computerfreak90
 
Nicht so leicht zu realisieren?
Java: 
new Socket("adresse", port)
und schon steht die Verbindung.
Mit getInputStream() und getOutputStream() danach eben Streams daraus erzeugen
und einfach Daten reinschreiben.

UDP: Bloß nicht, außer du weißt ganz genau was du tust.
Bei UDP hast du keine Garantie, wie die Daten ankommen.
Ob die Daten von einem Send einmal, mehrmals oder gar nicht ankommen;
sowie die Reihenfolge sind komplett offen.
Natürlich kann man da künstlich Prüfdaten mitschicken
und ggf. etwas nochmal übertragen,
aber TCP erledigt das schon alles intern für dich.
(Vorteile von UDP sind dafür Broadcast/Multicast und etwas schnellere Übertragung)

Datenformat:
Möglichkeiten gibts viele, man kann sich auch einfach selbst was ausdenken.
Was für Daten sollens denn sein?
 
Das "nich so leicht zu realisieren" war auf java bezogen, denn dort gibt es keine asynchonen funktionen wie socket.beginSend(); etc.
Da muss man alles mit threads machen, was meiner Meinung nicht so einfach zu verstehen ist.
Zu den Daten, also ich will die Haussteuerung abfragen und bedienen d.h. offene Fenster sehen und in welchemraum noch Strom verbraucht wird.
Diese daten bekomme ich aus einem c# programm und würde sie gerne nach java übertragen.
Wenn du mir ein paar methoden und formate nennen kannst wäre es schön
Dann suche ich mir das beste für meine zwecke aus.
Dank an alle Computerfreak90
 
Meiner Erfahrung nach sind Packet-Strukturen am besten dafür. Als Protokoll verwendest du TCP und teilst dann die Daten folgendermaßen auf.
PacketID (1 Byte): Die Eindeutige Identifikationsnummer des Packets.
SubID (1 Byte): Eindeutige Identifikationsnummer der Datenart.
Length (2 Bytes): Menge der Daten.
Data (Length Bytes): Daten.
Signature (Optional, 1 Byte): Instanzspezifische Signatur zur Überpüfung der Packetdatenvollständigkeit.

Damit hast du immer Packetgröße von 5 + Length Bytes.
So kannst du mithilfe der PacketID und der SubID schnell die Packete sortieren und ihren Inhalt zu "erahnen". Dann kannst du z.B. per switch oder sowas einfach auf Details eingehen. Die Signatur ist dafür da, um zu prüfen, ob das Packet auch vollständig angekommen ist. Deshal ist das Signaturbyte auch das letzte Byte. Wenn etwas unklar ist, frag einfach. So handhabe ich zumindest meine Netzwerk-Kommunikation.

Mfg
JustShinigami
 
Wenn man jetzt bei TCP bleibt: Wozu Paketid und Signatur?
Dass ein Paket genau einmal (und die Pakete richtig geordnet) ankommen ist garantiert
(solang die Verbindung steht).
Und zur Signatur: Wenn genug Byte für die Längenangabe empfangen sind sollte es passen.

@Allgemein: Wie Shinigami schon sagt, es würde kein Problem sein,
einfach auf XML etc.etc. zu verzichten.
 
Danke für die Hilfe.
Ich werde es in der Art so machen, wie JustShinigami das vorgeschlagen hat.
Nun kann ich anfangen, aber ich weiss nicht, ob ich immer alle Daten senden soll oder nicht.
Natürlich kann ich auch für jede Kategorie eine eigene nummer Definieren.
Was meint ihr dazu?
mfg
Computerfreak90
 
Ya, es ist üblich, permanent daten zu schicken. Wenn du keine Aktualisierung senden willst, weil sich das nur nach einer bestimmten Zeit, z.B. alle 2 Sekunden oder sowas, aktualisiert, dann sendest du, während du keine neuen daten hast, einfach ein Packet mit der ID 0x00 (0), das sogenannte KeepAlive-Packet. Damit kannst du gleichzeitig prüfen, ob die Verbindung steht oder nicht. Den Dateninhalt kannst du leer lassen, da das KeepAlive nur dazu dient, die Verbindung aufrecht zu erhalten.

Wie sheel erwähnte, ist die Signatur eigentlicb nicht wichtig, da tcp für dich schon alles macht. Jedoch benutze ich es sicherheitshalber trotzdem. Ob du nun eine Signatur mitschickst oder nicht, ist deine Entscheidung. :) (Darum auch optional)

Wenn etwas unklar ist, einfach fragen.

Mfg,
JustShinigami
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück