Wie kommuniziert man mit einem Dienst?
-
Hallo,
ich habe einen Dienst und ein kleines Programm welches den Status anzeigt.
Bis jetzt schreibt der Dienst seinen Status bei änderungen in eine Datei und das Programm liest es aus.Das ist so natürlich nicht wirklich optimal und es soll nur mehr angezeigt werden.
Ca. 40 Felder mit einem String die sich sekündlich ändern (können).Wie kommuniziert man mit einem Dienst?
Ich könnte einen TCP/IP-Server bauen, aber das erscheint mir doch zu aufwendigMerkwürdigerweise habe ich zu diesem Theman weder in google noch in diesem Forum was gefunden.
Hat da bitte mal Jemand einen Link für mich.Danke
Stefan
-
Pipes, TCP/IP oder Messages würde ich sagen ...
-
Zwischenbericht: Ich schaue mir gerade named pipes an
Belli schrieb:
Pipes, TCP/IP oder Messages würde ich sagen ...
Pipes: siehe oben
TCP/IP: entspricht eigentlich pipes nur ohne fehlerbehandlung
messages: ein dienst kann keine nachrichten empfangen. er könnte diese senden und daten über atoms oder globales speichern übertragen.Stefan
-
Spricht eigentlich was dagegen GlobalAddAtom zu verwenden?
Funktioniert zwar nur lokal, dafür aber einfachter.Es geht wie gesagt um ca. 40 atoms die sich bei aktivität ändern.
Nachteil: Der Client müßte die Atoms im Intervalle x (z.B. 1 oder 5 Sekunden) auslesen um Änderungen mitzubekommen.
Bei Pipes würde der Dienst änderungen direkt an den Client versenden.
Natürlich viel eleganter.Haben Atoms Nachteile?
Sind sie langsam?Stefan
-
Hallo.
Können Dienste auf Dll's zugreifen? Wenn ja, wäre meine Idee shared memory (schnell). Oder fileviews (Netzwerk).
Gruß
Lars
-
fileviews nur mit exceptionhandling!
-
Ich halte Named Pipes imernoch für eine der besten Methoden um mit einem Service zu kommunizieren.
Atoms kannst Du auch verwenden. Sie sind schnell einfach. Oft zu einfach!
Nur frage ich mich warum Du komplexere Dinge über Atoms abwickeln willst. TCP/IP und Namen-Pipes funktionieren auch von fremden System aus. GlobalAtoms und Memory Mapped Files nicht.
-
Moin...
dank Euch allen.
Ich werde die named pipes verwenden.Das mit den Atom ist eher ne quick 'N dirty variante.
Named pipes haben nur den Nachteil, dass sie bei WAN Verbindungen weniger schnell/effektiv sind? Die Software soll nur im LAN laufen. Also bleibe ich dabei.
Stefan
-
Wieso sind named Pipes im WAN langsam? Verstehe ich nicht...
-
Martin Richter schrieb:
Wieso sind named Pipes im WAN langsam? Verstehe ich nicht...
Habe ich gelesen.
Die Reihenfolge im OSI müßte doch aufsteigend udp, tcp, named pipes sein.
Ausgehend von der Geschwindigkeit von Dateifreigaben allein schon per WLAN oder DLAN gegenüber Kabel läßt es mir aber auch plausibel erscheinen.
-
Ich finde diese Geschwindigkeits Diskussion albern, das wirst Du kaum messen können.
Wieviele MB möchtest Du den durch die Gegend schaufeln?Schau Dir mal an was an Datenströmen mit Namedpipes und MS-SQL Server läuft. TCP/IP ist da kaum messbar schneller!
Und dafür hast Du aber ein gesichertes Protokoll mit vernünftiger Struktur und musst nichts selber aushandeln oder prüfen ob nur halbe Pakete ankommen etc. Und Du kannst perfekt Overlapped IO zur Steuerung verwenden. Es ist simpel es gibt viele Beispiele:
http://msdn.microsoft.com/en-us/library/aa365603(VS.85).aspxUnd auch Multithreading ist easy wie sonst was:
http://msdn.microsoft.com/en-us/library/aa365588(VS.85).aspxIch frage mich jedesmal warum die Leute immer zu TCP/IP greifen...
-
Martin Richter schrieb:
Ich frage mich jedesmal warum die Leute immer zu TCP/IP greifen...
weil smtp einfach nicht mit named pipes funktioniert
Danke für die Links
-
Ich führe das ganze mal hier http://www.c-plusplus.net/forum/viewtopic-var-p-is-1605297-and-sid-is-ebe298be45ec3804b8c0c98397295f6d.html#1605297 weiter, da es ja nun nur noch um named pipes geht und das sonst keiner findet.
-
Das wichtigste Argument für TCP/IP ist IMO dass man dann auch von anderen Betriebssystemen aus zugreifen kann.
Wenn das nicht nötig ist kann man denke ich genausogut Named Pipes verwenden.
