Komunikator internetowy - serwer

0

Witam. Piszę komunikator internetowy dla pewnej firmy.
Chcę napisać sewer na linuksie w oparciu o tzw. forking. Serwer tworzy procesy potomne, a każdy proces łączy się z klientem. Teraz moje pytanie - w jaki sposób mogę komunikować się między procesami w linuksie? Mam np. tablicę globalną socketów klientów. W serwerze opartym o wątki, tablica będzie widoczna dla wszystkich, ale jeśli chodzi o udostępnienie tej tablicy między procesy to nie mam pojęcia co zrobić ;( Proszę o pomoc ...

0

Potoki, IPC Cie interesuja. Funkcje pipe, shmget i takie tam.

0

HM. A może dać sobie spokój z forkami a zrobić tylko na samych wątkach ? Nie będzie prościej i szybciej? Tylko pytanie czy lepiej ;) ...

0
szczepanczyk napisał(a)

HM. A może dać sobie spokój z forkami a zrobić tylko na samych wątkach ? Nie będzie prościej i szybciej? Tylko pytanie czy lepiej ;) ...

Kazdy watek ma swoj wlasny stos, podobnie jak kazdy proces, z tym ze kazdy proces ma wlasna przestrzen adresowa, wiec watki wydaja sie byc lepszym rozwiazaniem. Duzo jeszcze zalezy od tego jaka funkcje ma pelnic serwer w Twojej komunikacji. Czy ma posredniczyc tylko w uwierzytelnianiu i nawiazywaniu polaczen, czy moze jeszcze w rozmowach ?

Do tej tablicy, o ktorej pisales uzylbym po prostu pamieci dzielonej i po sprawie.

0

Serwer ma robić wszystko, czyli:

  • zalogować klienta (dodać do tablicy klientów)
  • odebrać wiadomość od klienta i skierować ją do innego klienta
    ...
    ...
  • wylogować klienta na jego żądanie (usunąć z tablicy klientów)

Może w przyszłości jakiś transfer plików czy coś w tym stylu.

0

A nie lepiej będzie tutaj użyć wątków? Bo zauważ że w twoim rozwiązaniu nie bardzo masz możliwości bezpośredniego globalnego zarządzania tymi procesami potomnymi. Użycie wątków rozwiązałoby także twój drugi problem -> mógłbyś mieć bez problemu dane globalne synchronizowane mutexami.

Swoją drogą mam podobny program jak to co tutaj przedstawiłeś (ale z użyciem wątków) - tzn w sensie samej komunikacji i łączenia się klientów, bo robi zupełnie co innego ;) i w miarę sensownie to działa.

0

Jestem jeszcze trochę zielony w tych sprawach i boje się jednej rzeczy, o której czytałem. Mianowicie, jeśli serwer będzie uruchomiony na wątkach, to w przypadku wysypania się jednego z wątków(na skutek jakiegoś błędu w komunikacji z klientem) jest prawdopodobne, że wysypie się cały serwer. Jeśli będą to procesy potomne, to wysypie się tylko ten jeden proces. Reszta zostanie nienaruszona.

Shalom: ile klientów obsługuje Twój serwer ?
U mnie docelowo myślę że będzie około 10000-20000 . I przyznam się, że nie wiem czy to dużo czy mało ...

0

I chcesz odpalić 20000 procesów? To dość sporo. Testowałeś czy serwer sobie poradzi z taką ilością?
Jeśli odpowiednio obsługujesz błędy, to nie ma takiej możliwości jak "wysypanie się" czegokolwiek. Przecież każda funkcja ma możliwość sygnalizowania że wystąpił błąd, więc musisz po prostu to sprawdzać i odpowiednio reagować na takie zdarzenia.
Ilość klientów w moim przypadku jest ograniczona teoretycznie jedynie wielkością tablicy która przechowuje dane klientów. W praktyce nie testowałem tego na większej ilości niż 20-30, więc cieżko mi powiedzieć jak by to wyglądało dla znacznie większych ilości wątków.

0

Dla takich liczb moim zdaniem na zwyklym pececie musisz sobie odpuscic rozmowy za posrednictwem serwera tylko zostawic mu zestawianie polaczen i uwierzytelnianie, poniewaz za duze beda obciazenia.

Dalbym w takiej sytuacji kilka procesow zarzadzajacych cala komunikacja i odpowiednio rozdzielajacych zadania, nawet na watki. Oczywiscie polaczenia kolejkowane i obslugiwane w miare mozliwosci, co oczywiscie w przypadku zostawienia serwerowi tylko uwierzytelniania nie odbije sie tak bardzo na userach.

0

Ja tam sie nie znam, ale sie wtrace. otoz mam pytanie dot tej opcji gdzie serwer nie obsluguje komunikacji a jedynie uwierzytelnianie. moze jestem glupi i nie wiem co pisze, ale jak utrzymac komunikacje przez internet miedzy dwoma klientami bez publicznego IP bez posrednictwa serwera?

0

Zauważ że autor pisze ten komunikator dla jakiejs firmy, ergo najprawdopodobniej wszystkie korzystające komputery są wewnatrz sieci.
Swoją drogą zastanawia mnie kto zatrudnia do pisania czegoś takiego początkującego programistę ;]

0
Shalom napisał(a)

Zauważ że autor pisze ten komunikator dla jakiejs firmy, ergo najprawdopodobniej wszystkie korzystające komputery są wewnatrz sieci.
Swoją drogą zastanawia mnie kto zatrudnia do pisania czegoś takiego początkującego programistę ;]

Serwer będzie miał publiczne IP, ponieważ większość klientów firmy ma w domu NAT.

Shalom:

  1. To, że wątki są najprostszym rozwiązaniem, nie oznacza, że są najlepszym. Tu proponuję abyś poczytał sobie np. The Definitive Guide to Linux Network Programming Keira Davisa, i popatrzył na kody źródłowe serwerów takich jak np. Apache. Jak myślisz dlaczego nie zastosowali samych wątków ?

  2. "Jeśli odpowiednio obsługujesz błędy, to nie ma takiej możliwości jak "wysypanie się" czegokolwiek." Tutaj poczytaj sobie: Hacking, Sztuka Penetracji., Jona Ericksona. Dowiesz się dokładnie cóż to jest np. przepełnienie bufora i dlaczego nie wolno myśleć o kodzie źródłowym tak jak o uruchomionym programie, no i wtedy zrozumiesz dlaczego jest tyle łatek do Windowsa czy różnych exploitów w internecie.

Zanim zaczniesz kogoś oceniać, uważaj bo może się okazać, że to Ty jesteś do tyłu w temacie.

Co do serwera to zdecydowałem, że zrobię go w oparciu o procesy potomne, gdzie w każdym będzie pracowało kilka wątków. Komunikacja poprzez pamięć dzieloną, tak jak napisał t0m_k-tmp.

Pozdrawiam.

0
szczepanczyk napisał(a)

Dowiesz się dokładnie cóż to jest np. przepełnienie bufora i dlaczego nie wolno myśleć o kodzie źródłowym tak jak o uruchomionym programie, no i wtedy zrozumiesz dlaczego jest tyle łatek do Windowsa czy różnych exploitów w internecie.

Mógłbyś rozwinąć ten temat?

0

Chodzi mi tutaj o to, że odgórne założenie, że przewidzi się wszystkie potencjalne błędy jest niedorzeczne.
Dlatego wolę się jakoś zabezpieczyć, gdyby coś w przyszłości wystąpiło i napisać program tak, że jeśli się coś stanie, to nie spowoduje zatrzymania całej aplikacji...

0

@szczepanczyk oczywiście że nie zawsze przewidzi się wszystkie błędy, ale prawda jest taka że jeśli się nie przewidziało czegos to jest to zwykły bląd w programie ;) Zdziwię cię ale wiem cóż to jest buffer overflow.

Możliwe że twoje rozwiązanie dla tak dużej ilości klientów będzie faktycznie dobre, ciężko mi oceniać.
Ale nadal wydaje mi się ze nawet samo przełączanie sie między procesami przy takiej ich ilości moze się okazać problematyczne.

0

A czemu nie uzyjesz np. jakiegos gotowego protokolu i oprogramowania np. XMPP? Moim zdaniem XMPP jest az nadto funkcjonalny i jest od ch... oprogramowania klienckiego i serwerowego, zarówno pod windows jak i pod linuks, zazwyczaj free i open source. ja na twoim miejscu uzylbym wlasnie takiego gotowego serva a klienta bym napisal swojego, np. w oparciu o biblioteke gloox.

Oszczedzisz sobie mase roboty i bedziesz mogl sie skupic na pisaniu klienta. kiedys bawiłem sie glooxem i jest całkiem fajny

0
szczepanczyk napisał(a)

HM. A może dać sobie spokój z forkami a zrobić tylko na samych wątkach ? Nie będzie prościej i szybciej? Tylko pytanie czy lepiej ;) ...

prosciej <ort>na pewno</ort> nie bedzie, watki w c++ to ort! dupska wielki :P dead locki, mem leaki, i cala masa najrozniejszych bledow wynikajacych z dynamicznego zarzadzania pamiecia i synchronizacji

0

@cepa ale komunikacja wielu procesów za pomocą pamieci współdzielonej też wymaga synchronizacji i właściwie niewiele się to będzie różniło ;] Jedyna faktyczna różnica to sposób kolejkowania, przełączanie kontekstu i ew sposób komunikowania się tych procesów z procesem głównym.

1 użytkowników online, w tym zalogowanych: 0, gości: 1