Hallo zusammen,

ich habe schon eine ganze weile hier mitgelesen und da ich jetzt auch mein erstes Problem habe, welches ich nicht so einfach durch andere User Beträge lösen kann, hab ich gedacht melde ich mich mal an und hoffe auch auf zahlreiche Antworten zu meinem Problem.

Aktuell bin ich an der Entwicklung zu einem, zumindest für mich recht interessanten Projekt, es geht dabei um die Analyse von empfangenen Daten. Diese Daten kommen von einem Bluetoothgerät. Dieses Gerät schickt mir an einen bestimmten Port eine XMLDatei (Ich denke der Aufbau des XML spielt hier jetzt mal keine Rolle).
Naja auf alle fälle, hab ich mir überlegt, einen kleinen Windows Dienst dafür zu schreiben, der sozusagen immer überprüft ob an diesem bekannten Port etwas angekommen ist. Ist dies der Fall, soll er die Daten entgegen nehmen und in eine Datenbank zwischen Speichern.

Soviel zur Theorie.

Aktuell bleib ich aber daran hängen, dass ich nicht weiß, wie ich das mit dem Abfragen des Port bewerkstelligen soll. Ich hab viel gegoogelt und bin immer wieder auf den System.Net.Sockets Namespace gestoßen. Da aber hierbei immer wieder von einer Server - Client Verbindung die Rede ist, kommt das für mich leider nicht in Frage, da ich ja keinen Client habe, der sich irgendwann meldet.

Hat sowas schonmal jemand gemacht?
Würde mich sehr freuen, wenn mir jemand antwortet und auch noch helfen kann.

Viele Grüße
Matthias

Hallo Madis82,

erstmal herzlich willkommen!

Hier im Forum gibt es eine Beispielanwendung die die Kommunikation zwischen einem TCP Client und einem TCP Server demonstriert.

In der Anwendung TCP_Server gibt es einen TcpListener, der auf einem bestimmten TCP Port lauscht, und die empfangenen Daten ausgibt.

Lass mal die beiden Programme aus der Demo laufen und sieh dir den Code an. Eventuell löst es schon dein Problem.

Hier der Link zum Download: http://dotnet-forum.de/files/folders/beispielprojekte/entry1758.aspx

Viele Grüße,
Jan

Hallo Matthias und herzlich Willkommen im Forum,

Madis82:

es geht dabei um die Analyse von empfangenen Daten. Diese Daten kommen von einem Bluetoothgerät. Dieses Gerät schickt mir an einen bestimmten Port eine XMLDatei (Ich denke der Aufbau des XML spielt hier jetzt mal keine Rolle).

Via Bluetooth ist in der Tat auch für mich ein interessantes Projekt, da ich noch nie etwas mit Bluetooth als Übertragungsmedium zu tun hatte.

Madis82:

Ich hab viel gegoogelt und bin immer wieder auf den System.Net.Sockets Namespace gestoßen. Da aber hierbei immer wieder von einer Server - Client Verbindung die Rede ist, kommt das für mich leider nicht in Frage, da ich ja keinen Client habe, der sich irgendwann meldet.

Der Namespace ist schon richtig und die Client-Server Verbindung auch. Selbst wenn es im ersten Moment nicht danach aussieht

Dröseln wir deine Anforderung einmal auseinander.

• Du hast ein Gerät welches dir etwas schickt; eine XML-Datei.
• An einen bestimten Port, also via TCP/IP-Protokoll.
• Du willst eine Anwendung welche an diesen Port lauscht um die gesendete Datei entgegenzunehmen.

Was hast du jetzt? Eine Client-Server Anwendung.
Der Client wird von deinem Gerät dargestellt, welches via TCP-Protokoll eine Datenmenge an einen bestimmten TCP-Port eines anderen Gerätes, welches als Server fungieren muss, sendet. Ob dabei WLAN, eine LAN-Kabel oder, wie in deinem Fall Bluetooth, als Transportmedium verwendet wird ist erst einmal sekundär.

Dein geplanter Windows Dienst stellt den Server dar. Ein Server ist nicht immer zwingend eine Maschine, die speziell für diese Aufgabe aufgestellt wurde. Auch eine Anwendung die einen Dienst bereitstellt, z.B. der IIS oder der DNS-Dienst, wird als Server bezeichnet.
Wenn du jetzt einen Dienst erstellst, der die Aufgabe hat an einem bestimmten Port auf eine bestimmte Datenmenge zu warten, ist dies per Definition ein Server.

Ich hoffe ich konnte ein wenig Licht ins Dunkel bringen
Falls du detailiertere Fragen zur Implementierung deiner Lösung hast, einfach wieder melden.

Servus,
Klaus

Hey,
dachte ja nicht, das das mit dem Antworten hier so schnell klappt. Hierfür schonmal vielen Dank.
Wenn ich dich und auch die Beispielanwendung richtig verstanden habe, muss ich mir keine Gedanken über die Client Seite machen, denn schließlich möchte ich ja nur "hören", ob dieser mir was schickt.

Bin ich da jetzt richtig in der Annahme?

Gruß
Matthias

Hallo Madis82,

ja, genau so ist es dein Client ist ja dein gerät

 

Herzliche Grüße

Lars

Ok das ist ja super.

Jetzt ist mir aber noch was aufgefallen, der Jan hat in seinem Post einen TcpListener angesprochen, der mir mittlerweile jetzt auch mehr sagt. Beim genaueren Betrachten des Code Beispiels wird hier aber ein Socket benutzt. Welche Technik ist jetzt die bessere Socket oder TCP Listener???

Gruß
Matthias

Hallo Matthias,

ob Socket oder Tcp Listener hängt nun stark von der Art der Datenübertragung ab. TCP ist ein Protokoll, also eine Vorschrift, wie Daten übertragen werden. So ist festgelegt, dass Client und Server sich verstehen können. Da geht es auch nicht um den Dateninhalt.
Vergleiche es mit 2 Personen, die sich Daten austauschen wollen. Diese haben nun mehrere Möglichkeiten zu kommunizieren. Also wäre ein Beispiel, dass man sich auf einen telefonischen Kontakt einigt und dass man Deutsch spricht. -> Hier also z.B. Netzwerk über TCP.

Es kommt also drauf an, wenn das Bluetooth Gerät über TCP kommuniziert, dann ist der TCP-Listener erste Wahl. Übrigens ist der TCP-Listener nur eine Kapselung von Sockets. Im Vergleich zu obigem Beispiel wäre Sockets das Telefon und TCP die Sprache Deutsch ;-)

Bei Sockets musst Du Dich um alles selbst kümmern. Du musst korrekte Byte-Ströme bauen, so dass diese der Gegenüber versteht und vor allem musst Du Dich auch um das Fehlerhandling selbst kümmern. Z.B. wenn die Daten nicht vollständig übermittelt wurden und ein Fehler zurückkommt etc.

Also wenn TCP, dann nimm den TCP Listener, wenn sogar vielleicht HTTP, dann am Besten den HTTP-Listener...

Grüße
Timo

Hey,

super wie ihr das hier macht, 4 verschiedene Leute antworten und alle können mir weiterhelfen. Wirklich super. Ich werd mich dann jetzt erstmal ans Werk machen.

Gruß
Matthias