[c#] Wysyłka informacji z "serwera" do kilku "klientów"

[Tartar 10]

Witam.

 

Muszę zrobić aplikację, która wysyła pewne dane do innych komputerów (przechwytywane przez tę apkę ale ustawioną jako "klient"). Tego typu wysyłka to dla mnie nowość i jestem z tego totalnie zielony (czasu na podszkolenie nie mam).

Aplikacja podczas startu czyta plik konfiguracyjny, w którym określone jest czy jest ona serwerem czy klientem, adres Ip i port z którego wysyłamy dane oraz lista adresów ip i portów (ten sam port dla wszystkich adresów docelowych) docelowych.

Gdy aplikacja jest ustawiona jako serwer ma za zadanie w określonych odstępach czasu połączyć się z bazą danych, pobrać pewne informacje i wysłać je do adresów docelowych określonych na podstawie informacji z bazy jak i pliku konfiguracyjnego.

Gdy aplikacja jest ustawiona jako klient ma odebrać tę informację i odpowiednio ją przygotować przed pokazaniem danych użytkownikowi.

Nie ma potrzeby by klient informował serwer, że otrzymał dane.

Prawie wszystko mam oprócz tej wysyłki i odbioru. po szybkim kursie z YT (prosty chat między dwoma komputerami) niby zrobiłem tę komunikację i po uruchomieniu aplikacji - zonk. Wywala mi błędy, że socket nie może to, nie może tamtego (w pętli dołączałem nowy komp i próbowałem na niego wysłać info).

Dane mogą być wysyłane na jeden adres a mogą być też pod kilka naraz (w zależności od tego ile kompów jest w danym dziale).

Jak mam zrobić by serwer wysyłał mi informacje na różne komputery? Czy każdemu adresowi IP tworzyć oddzielny socket na sztywno (może da się jakoś dynamicznie - bo liczba adresów ip może rosnąć)?

A może to trzeba ogarnąć w jakiś inny sposób?

Dane do przesłania to kilka liczb całkowitych (mogą to być duże liczby) rozdzielonych ';'.

 

Z góry dziękuję za pomoc.

[Auberon 240]

zadanie rekrutacyjne?

n klientów n socketów chyba że będziesz wysyłał sekwencyjnie do każdego z tego samego gniazda

serwer ma wysylać dane czy klijety maja je pobierać z serwera?

 

bo jeśli serwer rozsyła to klienty musza mieć otwarty port nasłuchu (socket) a jeśli odwrotnie to serwer nasłuchuje

 

poza tym REST API się kłania

[Karister 1533]

Jeśli miałbym wrzucić swoje trzy grosze:

 

Założenie, że aplikacja działa jako serwer lub klient na podstawie pliku konfiguracyjnego jest bez sensu. Po co wszędzie instalować kod, który w połowie nie będzie używany? Powinny być dwie aplikacje, które są instalowane tam, gdzie trzeba i robią to, co do nich należy.

 

Wracając do komunikacji, jeśli nie chcesz ręcznie konfigurować komunikacji po socketach, wziąłbym sprawdzone rozwiązanie i postawił kolejkę. Skoro ma być broadcast, to topic. Serwer na niego pcha komunikaty, a clienty subskrybują i wsio. Odpada konfiguracja socketów i całej komunikacji.

Propozycja REST API jest IMO tutaj nietrafiona, bo tu nie ma żadnych zasobów do wystawiania po HTTP. Do tego byłoby to push API, więc będzie pałowanie się z obczajaniem IPków. Ewentualnie w formie webhooka. Wtedy nie ma problemu z client discovery, ale za to każdy klient musi się zarejestrować/wyrejestrować w serwerze. A jeśli klient uruchomi się przed serwerem to lipa. Ale jak serwer się zrestartuje to game over. Idealne miejsce, by coś poszło nie tak. A topic rozwiązuje te problemy za darmo i służy właśnie do pushowania notyfikacji do wielu klientów. Więc zamiast kombinować, użyłbym rozwiązania, które właśnie do tego służy. Oczywiście broadcast po tcp/udp też jest ok, ale wymaga więcej konfiguracji i rzeźbienia w kodzie.

Edytowane 28 Października 2019 przez Karister

[Tartar 10]

Dzięki za odpowiedzi - zapoznałem się z obiema.

Jednak to co czytałem wczoraj wieczorem (i w nocy) spowodowało, że na razie muszę odłożyć robienie tego "przez sieć" - po prostu nie ogarniam na razie przykładów, które czytam.

Jednak znalazłem częściowe rozwiązanie - na kompach dam aplikację, która będzie pobierać dane częściej (bo z kilku komputerów) z bazy danych (zrobiłem procedurkę i odpowiednią tabelę do danych).

 

@Namonaki

Nie jest to zadanie rekrutacyjne a po prostu sposób by usprawnić przepływ informacji w firmie.

[januzi 24]

Pod windowsem trzeba odpalić apkę jako admin, żeby mogła podpiąć się do gniazd i nasłuchiwać (można ręcznie utworzyć regułki przy pomocy polecenia net).

 

Co do sposobu przekazywania danych, najlepiej zrobić listę i sobie cyklicznie przejeżdżać (jeśli ma być dużo). Jeśli nie, to bind każdego z osobna i pamiętanie, który jest gdzie.

[Bono[UG] 1627]

Jeżeli to wewnętrzna sieć firmy i jest postawiona na sensownych switchach, to może skorzystać z UDP multicast?

[Auberon 240]

Wracając do komunikacji, jeśli nie chcesz ręcznie konfigurować komunikacji po socketach, wziąłbym sprawdzone rozwiązanie i postawił kolejkę. Skoro ma być broadcast, to topic. Serwer na niego pcha komunikaty, a clienty subskrybują i wsio. Odpada konfiguracja socketów i całej komunikacji.

Propozycja REST API jest IMO tutaj nietrafiona, bo tu nie ma żadnych zasobów do wystawiania po HTTP. Do tego byłoby to push API, więc będzie pałowanie się z obczajaniem IPków. Ewentualnie w formie webhooka. Wtedy nie ma problemu z client discovery, ale za to każdy klient musi się zarejestrować/wyrejestrować w serwerze. A jeśli klient uruchomi się przed serwerem to lipa. Ale jak serwer się zrestartuje to game over. Idealne miejsce, by coś poszło nie tak. A topic rozwiązuje te problemy za darmo i służy właśnie do pushowania notyfikacji do wielu klientów. Więc zamiast kombinować, użyłbym rozwiązania, które właśnie do tego służy. Oczywiście broadcast po tcp/udp też jest ok, ale wymaga więcej konfiguracji i rzeźbienia w kodzie.

a to zwyczajnie nie prościej a by klienty łączyły się i pobierały dane z serwera po http a rest jako zastępstwo dla własnego binarnego protokołu ...

 

chyba web-serwis byłby prostszym sposobem uzyskania tego samego rezultatu

Edytowane 31 Października 2019 przez Namonaki

[Karister 1533]

REST był stworzony z myślą o zarządzaniu zasobami i w tym się dobrze sprawdza. Nie jest złotym środkiem na wszelką komunikację między aplikacjami. Jest bezstanowy, nietrwały i blokujący. Sprawdza się do zapytań o zasób po sieci, a ssie do wymiany komunikatów. Od tego są kolejki. Tak samo do wkręcania śruby jest śrubokręt, a nie młotek. I choć można wbić śrubę młotkiem, to efekt zapewne będzie przeciętny.

 

Nikt też nie pisze o własnych protokołach binarnych. Implementacje kolejek są gotowe i używają TCP.