Was ist mit TCP/UDP oder Bluetooth(SerialPort oder GattService)?

Du meinst quasi eine Fernwartung?

Klar, möglich ist das allemal.

Man kann es kompliziert oder relativ handlich machen.

@DTF stellt da schon die richtigen Fragen. Nur würde ich persönlich wahrscheinlich gar nicht auf so tiefer Ebene arbeiten, sondern bekannte Datenprotokolle nutzen, wie z.B. MQTT/AMQP.
Generier' dir mittels z.B. QuickType ein paar JSON-Schemata, die du direkt in C#/Swift verwenden kannst und lass das Übertragungsprotokoll JSON über MQTT/AMQP laufen.

Dann brauchst du dich nicht extra um Sockets o.Ä. kümmern. Zieh' dir eine entsprechende Bibliothek rein und konfigurier den Client deinen Wünschen entsprechend auf beiden Seiten. Der einzige "Nachteil" bei MQTT z.B. wäre dass du einen zentralen Broker brauchst.
Richte dir einen RasPi ein, installiere mosquitto sudo apt install mosquitto mosquitto-clients und Abfahrt. Kriegt man in einem Tag implementiert, auf beiden Seiten.

Ähm, sorry, aber MQTT?

Nicht nur der Broker, sondern auch dass es ein asynchrones Message Queuing ist und auf dem Mobilgerät keine direkte Änderung sichtbar.

Wenn es darum geht Daten mit dem Programm auszutauschen dann bin ich klar bei REST Endpoints.

Zum Programm bedienen wäre Remote Desktop oder eine Fernwartung wie Teamviewer die Wahl.

Also zum bedienen, also eine Art "Fernbedienung", da wäre Bluetooth mit GATT brauchbar. Nicht immer hat man ein WLAN Netzwerk zur verfügung, Bluetooth ist schon in vielen Geräten drin. Hat man nun eine GATT-Characteristic READ/NOTIFY, kann man via GattCharacteristicInstanz.notify() mitteilen das sich der Wert geändert hat. Kann man in wenigen Stunden einbauen, sogar in Minuten, wenn man sich nicht einlesen muss.

MrTrebron schrieb:

Ähm, sorry,

Kein Problem

MrTrebron schrieb:

aber MQTT?

Ja, MQTT. Richtig. Das ist ziemlich genau der Einsatzzweck dafür. Schnell und unkompliziert Daten hin- und herschieben.

MrTrebron schrieb:

Nicht nur der Broker, sondern auch dass es ein asynchrones Message Queuing ist und auf dem Mobilgerät keine direkte Änderung sichtbar.

Jegliche Netzwerksachen sind inherent asynchron. Das Argument zieht IMO nicht.
Ich verwende MQTT auf tausenden (ja, wirklich) Maschinen im Feld per Mobilfunk (2-4G) um sowohl Daten auszutauschen, als auch Einstellungen zu ändern und Applikationen zu manipulieren/steuern. Im lokalen Bereich reden wir über Millisekunden, die kein Nutzer dieser Erde als großartige Latenz wahrnehmen würde und selbst im Mobilfunkbereich reden wir über 2 Sekunden von Nachrichtenversand bis Ankunft durch zig Ebenen zum Kundenportal.

MQTT ist nur das Transportprotokoll, ähnlich wie HTTP(S). Natürlich kann man MQTT auch "verlangsamen", wenn man ellenlange Daten schickt, die aufwändig prozessiert werden müssen.

Ein großer Teil aller Smart-Home-Geräte verwenden ebenfalls MQTT als Übertragungsprotokoll, was u.a. auch zu der geringen Latenz zwischen Knopfdruck auf dem Telefon und Aktivierung des Geräts führt.

Ich behaupte auch hier, dass MQTT eine weitaus sinnvollere Lösung ist, als in .Net den halben Netzwerkstack hochzuziehen, bis man an den Punkt kommt, dass man in einer handelsüblichen Anwendung die Schnittstellen hat. Ist mMn overkill.
Habe ich bereits auch implementiert, aber für deutlich komplexer Anwendungen mit intensivem Datenaustausch.

MrTrebron schrieb:

bin ich klar bei REST Endpoints.

Ich nicht, s.o. REST hat natürlich auch seine Stärken, aber eher wenn es um einen wirklichen Datenaustausch geht. Nicht zum Fernsteuern einer kleinen Applikation.

MrTrebron schrieb:

Zum Programm bedienen wäre Remote Desktop oder eine Fernwartung wie Teamviewer die Wahl.

Auch hier bin ich anderer Meinung. Wenn ich einer Applikation sagen will "führe Funktion X aus", dann will ich nicht ein RDP öffnen, mich anmelden und dann einen Knopf drücken. Wenn ich eine kleine App auf dem Handy habe, wo das mit Knopfdruck oder gar mit einem Assistenten geht, ist das viel angenehmer.

Der TO hat unter anderem danach gefragt seinen PC fernsteuern zu können. Dann muss er auch ein entsprechendes Programm dazu nutzen. Kommt halt drauf an was man an Geräten hat, welchen Einsatzzweck.

MQTT als genau dafür vorgesehen und SOAP oder REST als asynchron zu bezeichnen, ist schon mutig.
MQTT für Sensordaten -> Super
SOAP oder REST für den Abruf oder die Daten von Übertragung inklusiver direkter Rückmeldung -> Top

Wenn ich eine Anwendung fernsteuern will, brauche ich zugriff auf die Oberfläche, ansonsten ist es keine Fernsteuerung, egal ob man nun MQTT, SOAP oder REST nimmt.
Das sind alles nur Interaktionen mit Methoden der Anwendung.

Da der TO aber nicht so genau sagt was er will, ist das hier alles nur wildes raten mit ungeputzter Glaskugel.

Miniwebserver über httplistener. Dann kannst Die Application im Browser von jedem Gerät bedienen.

Bin gerade bei einer solchen Sache dran. Funktioniert super.

Ich kann dir nochmals Bluetooth empfehlen. Machste eine App mit BLE GATT server, eine Characteristic mit READ, WRITE und NOTIFY. Auf Serverseite liest du den Wert aus und stellt ggfs. den Slider ein. Wenn du aber auf Serverseite den Wert änderst kannst du den Client Informieren(Notity), also bescheid sagen, hey der Wert ist neu. Dann die Lautstärke einstellen.

Auf Windows Seite kannste das mit WinRT, einer UWP-APP, aber auch mit z.B. dieser Lib machen:(keine Ahnung wie mit IOS, ich nutze keine Apple Produkte, aber Android z.B. hat da alles OnBoard)
github.com/inthehand/32feet

Wenn du das auf Window ohne WinRT, keine UWP-APP und kein Packet nehmen willst, geht auch auf die harte Weise.
Die Bluetooth Apis BluetoothFindFirstRadio, BluetoothFindNextRadio etc. sind in dem Fall nicht geeignet, die listen nur gekoppelte Geräte, BLE muss aber nicht gekoppelt sein. Dann musst du die Socket API nehmen, also eine Socketverbindung.(WSAStartup, WSALookupServiceBegin, etc...)

Also irgendwie klingt deine Beschreibung immer noch recht schwammig.

Daten in Echtzeit?
Daten von Windows zu Smartphone pushen?
Daten vom Smartphone nur abholen?
Daten vom Smartphone ändern?

Sind Smartphone und PC physisch nah beieinander?
Oder muss es schon über WLAN Reichweite gehen?
Oder gar über eine Internetvervindung?

Kannst du für IOS Apps entwickeln?

Dann wäre es doch eine glorreiche Idee das mal auszuprobieren. Ist dir das dann zu viel, liefer einfach eine kleine Webseite aus(wie Dive schon erwähnte). Dann kannst du das via Webbrowser steuern und musst keine App machen.

@TomTheCoder15

Schau mal auf mein öffentliches Facebook-Profil. Da habe ich heute zwei kurze Vorschauvideos hochgeladen und weiter hinten findet man ein paar Bilder.
Es wird eine Gastronomie-Kassenanwendung.

Auf dem PC läuft eine VB.NET Anwendung mit einem httplistener (quasi als Webserver).
Die vom Smartphonebrowser (oder auch jedem anderen Browser) angeforderten Webseiten werden in der .NET Anwendung on the fly generiert und ausgegeben.
Die aufgerufene URL kann ja verschiedenen Parameter oder einfach nur verschiedene html-Seitennamen aufrufen - so kannst Du identifizieren was die Browseranwendung gerade möchte und entsprechend in der .NET Anwendung reagieren.

Auf meinem linken Beispielvideo geschieht folgendes:
Bei jedem Klick auf eine "Taste" (= <TD> Element mit Link drin) wird ein Artikel in der VB.NET Anwendung verbucht und dann wird mit "FERTIG" alles vom VB.NET Anwendung an den Drucker geschickt. Das Smartphone ist ein "dummes" Anzeigegerät für HTML/CSS Seiten.

facebook.com/roland.berghofer/

@dive26
Ein wichtiger Hinweis bezüglich der Sicherheit. Alles mit SSL/TLS verschlüsseln!!! Wenn die Betreiber den Kunden WLAN nutzen lassen und das im selben drin ist, du aber eine nicht verschlüsselte Verbindung hast, kann ich alles ausspähen(mit Wireshark), evtl. könnte ich bestellen, nach erhalt eine Stonierung ausführen, so das ich z.B. gratis Getränke bekomme.

@'dive' bei dir werden die Webseiten tatsächlich "on the fly" generiert?
Verwendest du dann eigene Templates in die dein Webserver (httplistener) mit Daten und den geforderten Controls generiert und ausliefert?

Ich würde ja behaupten das wäre hier ein wenig zu viel des Guten.

Was halt ein bissl mehr Aufwand ist, ist es dass im Web die Änderungen auch ohne Refresh time ankommen.
WebSockets wäre da etwas was man im Javascript der Webseite nutzen könnte um vom Server Änderungen gesendet zu bekommen.

Die Frage ist ja immer auch, ist der Nutzen den Aufwand wert?
Also für das Fernsteuern der Lautstärke und der, ich denke Mal, track Anzeige im heimischen WLAN.

@MrTrebron

Verwendest du dann eigene Templates in die dein Webserver (httplistener) mit Daten und den geforderten Controls generiert und ausliefert?

Ja schon fertige HTML/CSS die ich in einem String speichere und diverse Platzhalter mit string.replace() ersetze oder Elemente die ich in einer Schleife erzeuge.
Aber ohne dass die HTML-Templates durch meine Anwendung gehen, sind die nicht selbst "lebensfähig" .

Ist wieder so ein Projekt von mir, wo ich nebenbei lerne.
Hatte zwar bis jetzt alle meine Webseiten selbst gemacht, aber mit CSS bisher nur oberflächlich zu tun. Das ändert sich mit diesem Projekt hoffentlich.
Macht mir immer Spaß etwas neues anzugehen.

Die Frage ist ja immer auch, ist der Nutzen den Aufwand wert?Also für das Fernsteuern der Lautstärke und der, ich denke Mal, track Anzeige im heimischen WLAN.

Für die Lautstärkeregelung eines PCs gibts garantiert im PlayStore oder Appstore schon etwas fix fertiges .

@DTF

Wenn die Betreiber den Kunden WLAN nutzen lassen und das im selben drin ist

Ich denke, damit hast Du das Problem mit Deiner Frage bereits gelöst. In einem Kassennetzwerk hat kein Kunde etwas verloren .

Aber keine Angst. Auch ohne SSL habe ich Maßnahmen ergriffen, dass niemand ohne Zustimmung des Chefs mit dem System kommunizieren kann,
auch wenn dieser irgendwie ins Kassennetzwerk Zugang hat.
Man muss sich beim erstmaligen Zugriff auf das System am Hauptsystem anmelden (dazu ist Zutritt zur Hauptkasse und ein Passwort erforderlich).
Erst dann bekommt das Gerät Freigabe. Diese Freigabe kann jederzeit entzogen werden und verfällt auch automatisch nach einer gewissen Zeit.
Da ja wirklich ALLE Anfragen an das System über den httplistener gehen, kann ich das alles berücksichtigen. Auch wenn sich die IP ändert wird gesperrt.

@dive26
Gut das du dich auch darum sorgst und vorkehrungen triffst. Ich sage es generell lieber einmal zu viel, wie einmal zu wenig.

Aber wenn du Videos zeigen möchtest, lade sie doch bitte bei YT hoch(geht auch ungelistet). Ich hab kein Facebook Account und kann das nicht sehen. Vorteil wenn du das bei YT hochlädst ist auch, du brauchst nur die Url hier reinmachen, dann wird ein Player eingebettet.