Część,
Mam do was pytanie jak najlepiej skomunikować aplikację c# wpf, aplikacją na androidzie napisaną w xamarinie lub klienta uC nadającym przez gprs. Myślałem aby komunikacja odbywała się w strukturze klient-serwer-klient. Zależy mi na jak najkrótszym czasie opóźnień w przesyle danych, ponieważ przesyłane będą dane telemetryczne z uC i dane do sterowanie z aplikacji stacji bazowej do uC?
Z góry dzięki za pomoc.
0
0
Zależy mi na jak najkrótszym czasie opóźnień w przesyle danych
zainteresuj sie SignalR
0
Może być nawet po zwykłym http z serializacją do json-a czy XML-a.
Opracuj sobie jakiś zwarty protokół danych i obsługę timeoutów po stronie klienta i serwera.
Na GPRS masz chyba od 35 do 170 kbps więc komunikaty po 1k powinny działać bez problemów.
Jeśli BARDZO zależy Ci na szybkości to koduj komunikaty do postaci binarnej. Duże SCADY też nie odczytują częściej niż 1 s czy nawet kilka s.
Łatwo to chyba przetestować i sprawdzić.
Obiekt jest w lesie na Podlasiu, że tylko GPRS?
0
Może być nawet po zwykłym http z serializacją do json-a czy XML-a.
no nie moze, bo nie bedzie to realistyczne (nie bede najwiekszej wydajnosci co autor zaznaczyl)
0
Dzięki za rady, nie w lesie na podlasiu. Nie doprecyzowałem może być również 3G/LTE :D
0
fasadin napisał(a):
Może być nawet po zwykłym http z serializacją do json-a czy XML-a.
no nie moze, bo nie bedzie to realistyczne (nie bede najwiekszej wydajnosci co autor zaznaczyl)
Tak, ale jeśli to nie jest elektrownia jądrowa to będzie wystarczająco realistycznie. A na jakąś szybką reakcję to i tak się nie da w taki zdalny sposób i obiekt musi być dość autonomiczny dla przypadków awarii/przerw komunikacji.
Ja pamiętam z nie tak odległej przeszłości jak różne obiekty łączyło się modemami radiowymi z prędkością 9600 bodów.
Trzeba by wiedzieć co to za obiekt, jaka jest zmienność procesów i jaki jest REALNIE wymagany czas reakcji.
Jak ma być najlepiej to pewnie SignalR, jak napisałeś, albo coś własnego na Socketach.
0
Do telemetrii polecam protokół MQTT.