Użytkownik "Marek Wodzinski" <m...@O...mamy.to>

>>>>
>>>>> udp też się routuje
>>>>
>>>> Tak, wiem. Jednak w przepastnych czeluściach Internetu pakiet może
>>>> łatwiej zginąć niż w sieci lokalnej. ;)
>>>
>>> Przy udp w aplikacji dbasz o ewentualną retransmisję.
>>>
>>>> Poza tym w przypadku HTTP wystarczy, że na serwerze będę miał odpalony
>>>> serwer z obsługą PHP. UDP wymaga już osobnego serwera, który będzie
>>>> nadlatujących pakietów.
>>>
>>> Bo to się robi w drugą stronę: serwer odpytuje czujniki.
>>
>> I jak otrzymasz odpowiedź bez dedykowanego serwera nasłuchującego ?
>
> Jak napisałem powyżej - to czujnik słucha i czeka aż serwer go odpyta.
> Słucha czy dostanie odpowiedni pakiet. Jak mu pakiet podpasuje, to wysyła
> swój w odpowiedzi.

Czyli musi być na serwerze program nasłuchujący na tę odpowiedź. Może nie
być osobny, ale instalować serwer HTTP z PHP do obsługi SNMP ? Jakieś
nieporozumienie. Serwer HTTP z PHP o tyle ma sens, że taki hosting można
tanio mieć, ale by było w tym SNMP to mi się nie wydaje bo musiałby
obsługiwać jakąś wieloagentowość w ramach jednego adresu (jak hosty
wirtualne HTTP) lub mieć dedykowany adres IP (dodatkowy koszt). Ale do czego
to w ogóle zmierza ? Kolejna witrynka z pomiarami z kilku czujników ? Jak
dla mnie należy zrealizować:
- wykonanie i udostępnienie pomiarów,
- wymianę danych między różnymi lokalizacjami i użytkownikami
- publikowanie pomiarów

Do każdego z tych celów odpowiednie są różne protokoły. Pomiary można
udostępniać np za pomocą modbusa czy tak, jak napisałeś SNMP. Wymiana ...
XMPP. Publikowanie ... HTTP, XMPP. Może być właśnie tak, że jakiś serwer
obsługuje wiele aspektów wykorzystując różne protokoły.

Ja mam trochę rozwiązań do tego wszystkiego. Np takiego uniwersalnego
agenta, który:
- pobiera pomiary z różnych czujników i adapterów
- wymienia je z innymi agentami
- pokazuje lokalizacje stacji pomiarowych na mapie
- wyrysowuje wykres
- publikuje w komunikatorze

I nawet wydaje mi się interesujące wbudowanie SNMP, ale do pozyskiwania
pomiarów.