Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

MQTT i stos TCPIP Michrochipa

figa_miga 29 Sie 2016 23:15 3231 4
  • #1 29 Sie 2016 23:15
    figa_miga
    Poziom 19  

    Mam ogarnięte połączenie procka z serwerem za pomocą POST/GET. Potrzebował bym jednak czegoś w stylu MQTT... w stylu bądź dokładnie tego bo zapewne na serwerze łatwiej będzie postawić coś gotowego w standardzie niż dziergać to z palucha. Czytam i na razie mam mętlik, w zasadzie jeden przykład z MQTT na Michrochipa który kuleje, i najczęściej to dyskusje o Raspberry. Ogólnie jestem trochę cienki w te klocki i potrzebował bym jakiegoś naprowadzenia na trop.

    0 4
  • #2 30 Sie 2016 08:12
    JacekCz
    Poziom 36  

    Nie wiem na ile "jesteś cienki", i co robiłeś.
    Z pytania nie wynika, z czym konkretnie masz problem. Gotowca idealnie w punkt to się nawet nie spodziewaj, sorry, trzeba coś pokombinować.

    Lekką konkurencyjną biblioteką klasy "message queue" jest http://zeromq.org/ i projekty na niej budujące.
    Nie da się ukryć, wymaga dobrego poziomu w C, bliżej do wędki niż ryby, ale ryby też znajdziesz. Jaki to konkretnie procesor, ile ma RAM?

    Podoba mi sie że szukasz w MQ i wychodzisz z monokultury HTTP

    EDIT: zawsze uważam za stosowne, oswoić się z nową technologią, jej filozofią na komfortowym środowisku (czytaj: na pececie)

    0
  • #3 30 Sie 2016 11:17
    figa_miga
    Poziom 19  

    To http nie jest najgorsze, ale nie natychmiastowe a miło się klika gdy od razu jest reakcja. RAMu zostało jakieś 29kilo, procek PIC32MX6xx
    Problem to jest ogólny... jak do tego podejść od strony procka, bo do zabawy to można włączyć taką funkcję na komercyjnych serwerach IoT. Nie wiem co z SSL. Bo rozumiem że MQ to po prostu dodatkowa warstwa pomiędzy stosem TCP z którego muszę udostępnić kilka funkcji, a moim kodem "odbiera i wysyła" bufory. Zastanawiam się czy drobna przeróbka aktualnego softu nie dało by podobnych efektów (trzymanie otwartego socketa z serwerem). W tedy serwer mógł by do mnie zapukać?, nie wiem czy coś takiego przejdzie po http.

    Jak to qq działa?. Jeśli mam podpięte do serwera x urządzeń to wiadomość jest rozsyłana do wszystkich a dopiero urządzenie końcowe ma sobie z tego wyłuskać to co go interesuje?. Czy po prostu odpowiednia wiadomość jest już wysyłana do konkretnego odbiorcy?

    Jak znajdę chwilę to spróbuje przysiąść do jakiegoś przykładu, ale czym więcej będę wiedział przed tym lepiej dla mnie.

    0
  • #4 30 Sie 2016 12:47
    JacekCz
    Poziom 36  

    figa_miga napisał:
    To http nie jest najgorsze, ale nie natychmiastowe a miło się klika gdy od razu jest reakcja.


    Nie przesądzał bym (nieznanych) różnic w szybkości - nie ma sensu gwałcić protokołu wbrew jego naturze.

    HTTP to jest pytanie-odpowiedź, MQ to "przesyłka" bez ścisłego związku z odpowiedzią, odpowiedź może nie przyjść, przyjśc z innego serwera(*), w innej ilości itd. Fakt, że elementarne wysłanie w MQ może być szybsze, szybciej jakieś zdarzenie może się chronologicznie zakończyć, ale nie ma rezultatu.

    Więc pytanie "jaka jest natura twojego problemu", moim zdaniem warto zachowac naturalną spójność.



    figa_miga napisał:

    Bo rozumiem że MQ to po prostu dodatkowa warstwa pomiędzy stosem TCP z którego muszę udostępnić kilka funkcji, a moim kodem "odbiera i wysyła" bufory.

    Zastanawiam się czy drobna przeróbka aktualnego softu nie dało by podobnych efektów (trzymanie otwartego socketa z serwerem). W tedy serwer mógł by do mnie zapukać?, nie wiem czy coś takiego przejdzie po http.

    Jak to qq działa?. Jeśli mam podpięte do serwera x urządzeń to wiadomość jest rozsyłana do wszystkich a dopiero urządzenie końcowe ma sobie z tego wyłuskać to co go interesuje?. Czy po prostu odpowiednia wiadomość jest już wysyłana do konkretnego odbiorcy?


    1. Jest protokołem warstwy jakiejś tam (wyższej, apliakcyjnej) ANALOGICZNIE jak http. Myśle że na poziomie ideologicznych można rozumieć 'zamiast'. Nie jest "obcym ciałem" w TCP tylko aplikacją

    2. Firewal, NAT, te klimaty ... Http w nowszych wydaniach ma koncepcję websocket (przynajmniej tego słowa używają javowcy), ona de facto była zanim została zestandaryzowana i serwer może zapukać do klienta. Prawdopobnie nie odbywa się to "za darmo" ale jak się chce, to się ma.
    Nie robiłem, wiem że jest.

    3. w MQ raczej nie mówimy serwer, albo serwer ma inny sens. Klient kontaktuje się z brokerem. Podział serwer/broker wygląda inaczej MQTT ze względy na niższy koszt, inaczej w "'cięższych" jak AMQP ale ogólnie podobnie.
    Klient owszem selektywnie "odczytuje" ale nie dlatego że przewala przez sieć wszystko. Robi na brokerze subskrypcję na temat (subscribe to topic) i siecią nie gania co nie jest chciane. Po subskrypcji jest jak się spodziewasz, selektywnie.

    Topic ja rozumiem jako jakiś klucz (string) który identyfikuje "kanał" informacji, przy czym wiele klientów może ale nie musi zapisać się ten sam.

    0