Komunikacja między aplikacjami
Maciek
Pope�ni�em kiedy� ma�� aplikacj� zbieraj�c� dane z sieci czujnik�w
pomiarowych. Obecnie pojawia�a si� konieczno�� rozproszenia systemu,
postanowi�em wi�c rozdzieli� aplikacj� na serwer komunikuj�cy si� z
czujnikami i graficznych klient�w pobieraj�cych sobie dane z serwera.
Aplikacja zosta�a stworzona w �rodowisku C++ Builder, wi�c pierwszym
pomys�em by�o zastosowanie komponent�w Indy. Niestety nie mam �adnego
do�wiadczenia w tworzeniu wymiany danych mi�dzy aplikacjami i zacz��em
si� zastanawia� jaki protok� wymiany danych sobie stworzy�. Najpro�ciej
by�oby pewnie wykorzysta� prost� komunikacj� znakow�, czyli klient
wysy�a pytanie o warto�� okre�lonej zmiennej, serwer odpowiada i tak
cyklicznie przepytywa� ca�� list�. Ale ...
Obecnie aplikacja odczytuje oko�o 200 zmiennych na sekund�. Odczytywane
s� zmienne r�nych typ�w: binarne, ca�kowite, rzeczywiste. W wersji
klient/serwer mo�na by si� pokusi� o podzia� zmiennych, czyli ka�dy
klient ma inny zestaw. Tak siďż˝ zastanawiam, czy pojedyncze odpytywanie
nie spowoduje przytykania si� sieci, zw�aszcza przy dost�pie do serwera
np. przez wolne ��cze GSM. Trzeba oczywi�cie wzi�� pod uwag� mo�liwo��
zwi�kszenia liczby odczytywanych zmiennych. Mo�e wi�c jednak pomy�le� o
robieniu paczek danych i/albo u�y� do tego protoko�u binarnego?
B�d� wdzi�czny za wszystkie uwagi, np. odno�nie sensu stosowania Indy 9
i ewentualnych alternatyw, a tak�e za linki do przyk�ad�w realizacji
tego typu komunikacji.
--
Pozdrawiam
Maciek
Paweł Kierski
> Witam
>
> Popełniłem kiedyś małą aplikację zbierającą dane z sieci czujników
> pomiarowych. Obecnie pojawiała się konieczność rozproszenia systemu,
> postanowiłem więc rozdzielić aplikację na serwer komunikujący się z
> czujnikami i graficznych klientów pobierających sobie dane z serwera.
[...]
> Będę wdzięczny za wszystkie uwagi, np. odnośnie sensu stosowania Indy 9
> i ewentualnych alternatyw, a także za linki do przykładów realizacji
> tego typu komunikacji.
http://www.msobczak.com/prog/yami/
tutorial, da pojęcie o łatwości używania:
http://www.msobczak.com/prog/yami/impl/files/cpptut.html
--
Paweł Kierski
ne...@pkierski.net
Maciej Sobczak
> > Będę wdzięczny za wszystkie uwagi, np. odnośnie sensu stosowania Indy 9
> > i ewentualnych alternatyw, a także za linki do przykładów realizacji
> > tego typu komunikacji.
>
> http://www.msobczak.com/prog/yami/
> tutorial, da pojęcie o łatwości używania:
> http://www.msobczak.com/prog/yami/impl/files/cpptut.html
Dziękuję za reklamę ;-), ale może dodam kilka drobiazgów.
Nie warto robić takiego systemu na zasadzie odpytywania, bo przy
pomiarach fizycznych odpytywanie jest najczęściej albo jałowe jeśli
jest zbyt częste, albo pomijające ciekawe zmiany jeśli jest za wolne.
Lepiej odwrócić kierunek stymulacji i oprzeć się na subskrypcji - tzn.
niech czujniki (albo kontrolujący je serwer, zależnie od inteligencji
czujnika) wyznaczają rytm i niech wysyłają dane do klientów wtedy, gdy
warto je wysłać. Np. wtedy, gdy się gwałtownie zmieniają albo gdy
osiągają jakieś progowe wartości.
Wtedy oczywiście pojawia się ciekawy problem zarządzania subskrypcjami
(komu co wysłać), ale na dłuższą metę warto w to zainwestować.
Tak czy inaczej nie ma po co męczyć się z ręcznie obsługiwanymi
gniazdami, lepiej skorzystać z gotowców nastawionych na przesyłanie
komunikatów.
--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
Jacek
wzgledem czasu odbierania informacji przez klientow w czasie?
Maciej Sobczak
> A jak sie ma odpytywanie serwera do wysylania przez serwer komunikatow
> wzgledem czasu odbierania informacji przez klientow w czasie?
Nie rozumiem pytania.
Chodzi o szybkość? W sensie opóźnień subskrypcje są szybsze, bo od
wyprodukowania danych do ich wysyłki upływa krótszy czas. W sensie
wykorzystania przepustowości też jest lepiej, bo pakiety latają tylko
w jedną stronę a nie w obie.
Maciek
> Nie warto robiďż˝ takiego systemu na zasadzie odpytywania, bo przy
> pomiarach fizycznych odpytywanie jest najcz�ciej albo ja�owe je�li
> jest zbyt cz�ste, albo pomijaj�ce ciekawe zmiany je�li jest za wolne.
Zgoda, aczkolwiek ma to znaczenie raczej przy rejestracji tego typu
danych, a nie np. prezentacji chwilowych warto�ci. Na pewno nie ma co
powiela� tego mechanizmu, czyli je�li na etapie serwera _musi_ by�
czasowe odpytywanie (bo czujniki s� raczej "g�upie"), to rzeczywi�cie
bez sensu jest pisa� podobnie "g�upi" serwer, kt�ry te� trzeba czasowo
odpytywaďż˝.
> Lepiej odwr�ci� kierunek stymulacji i oprze� si� na subskrypcji - tzn.
> niech czujniki (albo kontroluj�cy je serwer, zale�nie od inteligencji
> czujnika) wyznaczaj� rytm i niech wysy�aj� dane do klient�w wtedy, gdy
> warto je wys�a�. Np. wtedy, gdy si� gwa�townie zmieniaj� albo gdy
> osi�gaj� jakie� progowe warto�ci.
> Wtedy oczywi�cie pojawia si� ciekawy problem zarz�dzania subskrypcjami
> (komu co wys�a�), ale na d�u�sz� met� warto w to zainwestowa�..
W sumie ta jednostanowiskowa aplikacja ju� tak dzia�a, tzn. poszczeg�lne
okna w momencie otwarcia wi��� swoje elementy ze zmiennymi w "module"
komunikacyjnym i przy zmianie warto�ci zmiennej wymuszane jest
od�wie�enie stanu powi�zanych element�w. Teraz musz� si� powa�nie
zastanowi� dlaczego chcia�em zrobi� 2 kroki do ty�u i montowa� jakie�
czasowe od�wie�anie element�w z jednoczesn� komunikacj� po sieci. To
musi by� staro�� ;-)
> Tak czy inaczej nie ma po co m�czy� si� z r�cznie obs�ugiwanymi
> gniazdami, lepiej skorzysta� z gotowc�w nastawionych na przesy�anie
> komunikat�w.
A mo�esz co� poleci� szczeg�lnej uwadze?
--
Pozdrawiam
Maciek
Maciej Sobczak
> > Nie warto robić takiego systemu na zasadzie odpytywania, bo przy
> > pomiarach fizycznych odpytywanie jest najczęściej albo jałowe jeśli
>
> Zgoda, aczkolwiek ma to znaczenie raczej przy rejestracji tego typu
Chodzi Ci o to, że w prezentacji graficznej można pominąć szczegóły?
Można, ale to jest tylko jeden z problemów. Drugi dotyczy
minimalizacji ruchu. Po co odpytywać serwer co chwilę (gdzie "co
chwilę" jest zależnie od tego jak te wartości są prezentowane, np.
wykres ma inne wymagania niż jedno pole z liczbą), jeśli się tam nic
nie zmienia?
Szczególnie, jeśli tych wartości jest dużo.
> > Tak czy inaczej nie ma po co męczyć się z ręcznie obsługiwanymi
> > gniazdami, lepiej skorzystać z gotowców nastawionych na przesyłanie
> > komunikatów.
>
> A możesz coś polecić szczególnej uwadze?
YAMI, link podany przez Pawła.
W realnych systemach tego typu znajdziejsz również Corbę, JMS, DDS,
AMQP. Wszystko ma zady i walety.