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.

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

do góry

Maciek wrote:
> 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
n...@p...net

do góry

On 24 Lis, 13:30, Paweł Kierski <n...@p...net> wrote:

> > 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

do góry

A jak sie ma odpytywanie serwera do wysylania przez serwer komunikatow
wzgledem czasu odbierania informacji przez klientow w czasie?

do góry

On 24 Lis, 18:23, Jacek <a...@o...pl> wrote:

> 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.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

do góry

Maciej Sobczak pisze:
> 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

do góry

On 25 Lis, 23:39, Maciek <m...@n...pl> wrote:
> > 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.

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.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

do góry