Komunikacja serwer-klient (idea)

Postawiono przedemna zadanie napisania systemu komunikacji pomiedzy serwerem a klientem.
Zaglebiajac sie w posty dotyczace tej tematyki wiele mowi sie o rodzinie komponentow INDY.
Czytajac o nich zdalem sobie sprawe ze ich wykorzystanie wcale nie jest trudne.
Ale zastosowanie ich do mojego konkretnego przypadku moze okazac sie nieco klopotliwe.

Moj przypadek:
Istnieje serwer z baza SQLite. Do niego jest podpietych okolo 50 klientow ktore rowniez gromadza dane w SQL-u.
Serwer moze wysylac polecenia do klientow a klienci wysylaja zgromadzone dane.
Biorac pod uwage ich liczbe trafser calej bazy nie wchodzi w rachube tymbardziej ze niektore informacje chcialbym miec "na biezaco"... (poza tym baza danych z dnia na dzien bedzie sie rozrazstac wiec interesuja mnie dane z konkretnego dnia - z zapytaniami sql-a nie mam problemu)

Mam siwadomosc ze wykorzystenie SQL Server 2000 rozwialo by problem ale zalezy mi na lokalnej bazie... Darmowej... Ktorej nie trzeba instalowac - to wlasnie oferuje SQLite.

Myslalem np o wysylaniu z klienta plikow o formacie xml i ich parsowanie przez serwer....
Ow pliki nie mialy by duzych rozmiarow a ze sa tekstowe wysylana byla by ich zawatosc wedle specyfikacji...
Rozwiazanie jednak jest nieco klopotliwe w realizacji... a wlasciwie czasochlonne...

A moze jakis system jezyka skryptowego?
Wysylanie tabel w formacie Kolumna1|Kolumna2|Kolumna3| a calosc poprzedzona unikalnym ID klienta oraz nazwa tabeli?

Moje rozwiazania o ile moga funkcjonowac wydaja sie nieco archaicze nie spojne...
A zalezy mi na dynamicznym systemie, nie zawieszajacym sie, latwym w zastosowani i spelniajacy moje oczekiwania...

Za pomysly z gory dziekuje :-) (wymagane komponenty - czy ich rodzina, sposob reprezentacji wysylanych danych i wszystko co zwiazane z tym postem)

ale w ogóle to gdzie jest problem bo ja to dwa razy przeczytałem i dalej nie wiem o co chodzi. Połączenie do bazy przez INDY????

Istnieje serwer z baza SQLite. Do niego jest podpiętych około 50 klientów
a zaraz potem

zależy mi na lokalnej bazie
no to trzeba się na coś zdecydować - albo lokalna baza BEZ wielodostępu albo normalny serwer BD (np. FireBird, MySQL, PostgreSQL, i pewnie jeszcze xxx innych) do którego można mieć dostęp (o ile ma zewnętrzne IP) z całego świata bez żadnych kombinacji

Już tłumaczę...

Otóż: interesują mnie rozwiązania nie wymagające wkladu finansowego zatem wiele juz (bardzo atrakcyjnych) pozycji odpada.
Druga sprawa sqlite do programu dolacza tylko dll-ke i w ten sposob mam do dyspozycji baze danych.
Nie ma zadnego ZEWNETRZENEGO silnika bazy ktory trzeba doinstalowywac... konfigurowac...

Otoz potencjalny uzytkownik instaluje program i ten juz jest gotow do uzycia... Bardzo mi zalezy na tej "prostocie" ze strony "konsumenta".

Oczywiscie sa darmowe rozwiazania: MySQL itp.
Dlaczego z nich nie skorzystam?
Poniewaz klient nie bedzie wysylac wylacznie typowych danych ale w przyszlosci rowniez grafike i dane innych typow zatem i tak jestem zmuszony do komponentow typy INDY badz pochodnych.

Aby jeszcze bardziej zaobrazowac zagadnienienie:

Program I Klient
Zawiera baze danych (SQLite) ktora powinien wysylac do serwera.

Program II Serwer
Odbiera baze danych z klienta (SQLite) i aktualizuje wlasna (SQLite)(o nowe pozycje wczesniej w niej nie wystepujace) jesli istnieje taka potrzeba.

Przyklad:
Powiedzmy ze klient w bazie danych zawieral tabele:
"Osoby" o kolumnach ID i Nazwisko

ID NAZWISKO
1 Kowalski
2 Nowacki
3 Stefanski

Klient wysyla tabele do serwera (w jaki sposob to najlepiej zrealizowac?) a serwer dodaje jej jeszzce jedna kolumne IDKlienta w rezultacie baza danych z ta tabela na serwerze bedzie miec nastepujaca postac:
ID NAZWISKO ID_KLIENTA
1 Kowalski KLIENT1
2 Nowacki KLIENT1
3 Stefanski KLIENT1

Mam swiadomosc ze uzywajac narzedzia typu SQL Server 2000 nie musailbym sie o nic martwic i calosc odbywala by sie automatycznie.
Ale lokalnosc w mojej pracy jest bardzo istotna.
Klient musi dzialac rowniez BEZ POLACZENIA z serwerem.
Moj pomysl to uwzglednia.
Wszak zalozenie jest takie ze program moze dzialac bez serwera 3 dni i po tym terminie udaje mu sie polaczyc ze swoja docelowa maszyna "nadrabiajac stracony czas" wysylajac serwerowi "ubytek danych".
Mam nadzieje ze rozwialem tym razem wszelkie watpliwosci.

PS
Dzieki Misiekd za zangazowanie w tym forum. Odwalasz kawal dobrej roboty [browar]

luster napisał(a)

Otóż: interesują mnie rozwiązania nie wymagające wkladu finansowego zatem wiele juz (bardzo atrakcyjnych) pozycji odpada.
ale za to trzeba napisać własny serwer, który będzie zarządał danymi, jakie przyśle klient - dla mnie patologia :/

Druga sprawa sqlite do programu dolacza tylko dll-ke i w ten sposob mam do dyspozycji baze danych.
Nie ma zadnego ZEWNETRZENEGO silnika bazy ktory trzeba doinstalowywac... konfigurowac...
Otoz potencjalny uzytkownik instaluje program i ten juz jest gotow do uzycia... Bardzo mi zalezy na tej "prostocie" ze strony "konsumenta".
no przecież jak masz serwer BD już zainstalowany na wydzielonej maszynie to u klienta nic się nie instaluje a jedynie (w zależności od serwera BD) dorzuca do katalogu aplikacji (albo windows\system|windows\system32) jedną bądź kilka dllek

Oczywiscie sa darmowe rozwiazania: MySQL itp.
Dlaczego z nich nie skorzystam?
Poniewaz klient nie bedzie wysylac wylacznie typowych danych ale w przyszlosci rowniez grafike i dane innych typow zatem i tak jestem zmuszony do komponentow typy INDY badz pochodnych.
a co to do MySQLa nie da się zdjęcia czy "dane innych typow" zapisać?? Przecież masz BLOBy i na dobrą sprawę możesz tam wcisnąć wszystko co nie jest "standardowym typem danych"

Mam swiadomosc ze uzywajac narzedzia typu SQL Server 2000 nie musailbym sie o nic martwic i calosc odbywala by sie automatycznie.
tego nie rozumiem już w ogóle - a MSSQL to się nie instaluje??? To jedna dllka jest wg Ciebie??? Tak pytam bo nie wiem co ma MSSQL, czego nie mają darmowe bazy. Chyba, że chodzi Ci o replikację. Ale jakoś nie znalazłem wersji embedded tegoż serwera a bez tego odpada 50% Twoich założeń.

Ale lokalnosc w mojej pracy jest bardzo istotna.
Klient musi dzialac rowniez BEZ POLACZENIA z serwerem.
to ja bym proponował zamiast jakies machlojki z wysyłaniem baz, plików, whatever do serwera po prostu napisać w programie procedurę AKTUALIZUJ DANE. Możesz przecież mieć na serwerze PostreSQLa a lokalnie SQLite i nic nie stoi na przeszkodzi, żebyś z jednego programu łączył się z obiema bazami. Jedyna niedogodność to potrzba napisania całej logiki bazy pod dwa serwry, ale jeśli się zdecydujesz np. na FireBirda (który też ma wersję embedded) to wtedy wszystko napiszesz tylko raz

Moj pomysl to uwzglednia.
Wszak zalozenie jest takie ze program moze dzialac bez serwera 3 dni i po tym terminie udaje mu sie polaczyc ze swoja docelowa maszyna "nadrabiajac stracony czas" wysylajac serwerowi "ubytek danych".
wszystko to uwzględnia mój pomysł (patrz parę linijek wyżej :))

Mam nadzieje ze rozwialem tym razem wszelkie watpliwosci.
Powiedzmy :).
Jeszcze taka drobna uwaga - jeśli np. po roku pracy Twoja główna baza będzoe miała np 2GB i klient będzie miał możliwość edycji czy kasowania danych dowolnie starych to jak sobie wyobrażasz aktualizację bazy bo ja tego nie widzę :/

Dzieki Misiekd za zangazowanie w tym forum. Odwalasz kawal dobrej roboty [browar]
nie ma za co [browar]

Jeszcze taka drobna uwaga - jeśli np. po roku pracy Twoja główna baza będzie miała np 2GB i klient będzie miał możliwość edycji czy kasowania danych dowolnie starych to jak sobie wyobrażasz aktualizację bazy bo ja tego nie widzę

Hmm klient gromadzi dziennie 20KB (albo i znacznie mniej) danych ktore sa przyporzadkowane wlasnie temu KONKRETNEMU dniu.
Nie moze ingerowac w dane ktore byly zapisane w przeszlosci a dostepu do glownej bazy nie posiada w ogole.
Kazdy rekord ma przyporzadkowana date.
Zatem serwer nie pobiera calej bazy a tylko konkretny dzien.
Jak widzsz problem z rozmiarami "paczek" odpada.
Zostaje mi tylko ten sam system komunikacji - przekazu informacji z klienta do serwera i aktualizacja glownej bazy.

Zaproponowales uzycie PostreSQLa na serwerze. Brzmi ok.

Jedyna niedogodność to potrzba napisania całej logiki bazy pod dwa serwry

Nie sadzisz ze teraz wlasciwie "tylko" to mam do zrobienia?? :d
Z kadym postem jak widac moj przypadek jest dokladniej opisany.
Wspomniales na temat FireBirda. Moglbys powiedziec nieco wiecej na ten temat?
Jak wygladalo by jego zastosowanie w moim przypadku?
Czy jest sens podczepiac pod aplikacje kolejna technologie?
(zastapiajac obecna)

PS

Mam swiadomosc ze uzywajac narzedzia typu SQL Server 2000 nie musailbym sie o nic martwic i calosc odbywala by sie automatycznie.

(miałem na mysli sam proces wymiany danych nad ktorym nie musialbym myslec - nie proces instalacji)

luster napisał(a)

Wspomniales na temat FireBirda. Moglbys powiedziec nieco wiecej na ten temat?
Jak wygladalo by jego zastosowanie w moim przypadku?
Czy jest sens podczepiac pod aplikacje kolejna technologie?
(zastapiajac obecna)

Nie wiem, co byś chciał wiedzieć. FB ma dwie wersję
a) serwer - normalnie instalowany, pełnoprawny serwer SQL z podzapyaniami, widokami, procedurami, wyzwalaczami itd. Zarówno na windowsa jak i linuxa
b) embedded - jak a ale z ograniczeniem do TYLKO JEDNEGO połączenia w danym czasie, cały "serwer" znajduje się w jednej dllce (jeśli masz też sortowani/wyszukiwanie po polskich znakach to dochodzi Ci biblioteka dla dla języka jezcze) + plik z bazą (bo FB zapisuje bazę do pliku, który można normalnie kopiować)

Co do zastosowania to jeśli i lokalnie i na serwerze baza wygląda tak samo to nie musisz jej dwa razy oprogramowywać, tak samo w aplikacji zmiana dostępu z lokalnego na zdalny polega jedynie na zmianie definicji połączenia. Jeśli interesuje Cię czym i jak się podpiąć do FB to tu się rozpisałem :p http://4programmers.net/Forum/viewtopic.php?id=94236 i w artach jest też artykuł o delphi i FB (ale obowiązkowo trzeba przeczytać komentarze do niego nawet wcześniej niż samego arta)

luster napisał(a)

Oczywiscie sa darmowe rozwiazania: MySQL itp.
Dlaczego z nich nie skorzystam?
Poniewaz klient nie bedzie wysylac wylacznie typowych danych ale w przyszlosci rowniez grafike i dane innych typow zatem i tak jestem zmuszony do komponentow typy INDY badz pochodnych.

Z własnego doświadczenia wiem, że MySQL bez problemu potrafi przechować grafikę czy inne dane dowolnego typu. Typem docelowym dla takiego obiektu jest BLOB (wystarczy tylko wiedzieć jak należy traktować dane tego typu tzn. czy bedzie to grafika, dzwięk itd.), więc nie widze żadnego problemu aby skorzystać z MySQL.