Budowa komunikatora internetowego

[mathiass213]

Część Wszystkim

Mam do was pytanie odnośnie budowy, zasad działania, implementacji dotyczącej komunikatora internetowego.
Oprogramowanie, program piszę w c++ wykorzystując bibliotekę boost aplikacja może być odpalono na różnych platformach.
Zamierzam umieścić dane rozmów użytkowników po stronie Klienta („Użytkownika”).
Zastanawiam się gdzie mam umieścić dane jakie użytkownik chce  przekazać adresatowi podczas rozmowy gdy 2 użytkownik nie będzie dostępny.

Moim pierwszym pomysłem jest umieszczenie danych w bazie danych po stronie severa zaszyfrowanych kluczem publicznym użytkownika wysyłającego wiadomości co uniemożliwi włamującemu się uzyskanie zawartości wiadomości (Nie wiem czy można to objeść nie jestem tak bardzo zaawansowany w kryptografii) użytkownika ale nie chciałbym przechowywać danych po stronie serwera.

Moim kolejnym pomysłem jest sprawdzenie czy użytkownik jest zalogowany/połączony z serwera i może mu wysłać wiadomości co jest głupim bo użytkownicy mogą uruchamiać aplikacje o różnych godzinach  więc wiadomość nie zostanie dostarczona.

Nie jestem pewien jak powinienem podejść do tematu za każdą radę/pomoc będę wdzięczny.

[Paweł Kraszewski]

Parę pytań:

1. Problem jest na zaliczenie czy rzeczywiście chcesz świadczyć usługę? Jak zaliczenie, to można ściąć niektóre rogi. Jak komercja i "Nie wiem czy można to objeść nie jestem tak bardzo zaawansowany w kryptografii"  - absolutnie nie jesteś do tego gotowy.

2. "po stronie severa zaszyfrowanych kluczem publicznym użytkownika wysyłającego wiadomości". To może odszyfrować tylko wysyłający, więc wracasz na początek problemu. Miałoby sens zaszyfrować kluczem publicznym odbiorcy - wtedy odbiera on wiadomość w dogodnym czasie i odszyfrowuje.

3. Jakie w ogóle masz założenia tego projektu? Przede wszystkim - w czym miałby być lepszy od istniejących rozwiązań OpenSource?


To, ze większość serwerów komunikatorów jest napisana w Erlangu (ejabberd i pochodne), Pythonie (Matrix), Rubym (Mastodon), Go (alternatywny serwer Telegrama), Javie (serwer Signala),  Ruście (alternatywne implementacje wcześniejszych) i praktycznie nic dużego w C++ powinno dać coś do myślenia...

[mathiass213]

Szybko mnie przejrzałeś. Dany program ma być jako praca inżynierska mam za zadanie zrobić  komunikator  internetowy z szyfrowaną komunikacją nie zamierzam świadczyć żadnych usług.
Na początku projektu zakładem żeby umościć dane po stronie serwera ze względu na łatwiejsze/uniknięcie niektórych problemów ale za nową kolegi zmieniłem założenia projektu i postawiłem na dane po stronie klienta i napotkałem dany problem i szukam odpowiedniego optymalnego rozwiązania np. widziałem jeszcze zapisywanie danych w postaci kolejki komunikatorów, do bazy danych lub też widziałem rozwiązanie w postaci stałego połączenia.
Kurcze ale babola strzeliłem z kluczem publicznym, masz racje odbiorcy...
Powinien napisać klucz który odebrał od użytkownika z którym chce się komunikować w czasie akceptacji znajomości czyli klucz publiczny a klucz prywatny nowego znajomego zostałby po stronie jego stronie do odszyfrowanie wiadomości.
Co do 3 pytania to po prostu chciałem poszerzyć swoją wiedzę w zakresie programowanie i w sieciach komputerowych.

[Paweł Kraszewski]

Szybko mnie przejrzałeś.

8 lat dydaktyki robi swoje...

Co do 3 pytania

Pytanie 3 było na przypadek komercji.

Praca zaliczeniowa ma kilka miłych cech:
* Możesz sobie pozwolić na skalowanie projektu na kilkudziesięciu/góra kilkuset użytkowników.
* Nie musisz zapewniać SLA dla klientów
* Ochrona przed złośliwymi użytkownikami/DoS/DDoS jest sprawą drugorzędną.
* Nie musisz się chrzanić z RODO/GDPR

Z językiem bym się bardzo zastanawiał nad tym C++. Naprawdę mało rozwiązań tego typu jest w nim pisane. Z kompilowanych języków najwięcej rzeczy "z pudełka" do takiego projektu daje Go, potem Rust. Go ma całą kryptografię, TLS-y, kompresję, serwery HTTPS w bibliotece standardowej.

Masz dwie główne topologie:
* Klient-Serwer (gwiazda, tryb store-and-forward z centralnym serwerem/serwerami, tak działa 99,9% komunikatorów)

Możesz popatrzeć na gotowe rozwiązania kolejek komunikatów (MQTT, AMQT). Jak pomyślę, serwer Mosquitto ma 95% potrzebnej funkcjonalności serwerowej zaimplementowanej bezpośrednio - pozostałe 5% załatwiłby mikroserwis przypięty z boku, zajmujący się managmentem i buchalterią. Genialną cechą Mosquitto jest to, że może tworzyć dynamicznych użytkowników na podstawie DN certyfikatu SSL i można robić dynamiczne ACL-ki do kolejek na bazie nazwy użytkownika. Klientów MQTT masz do każdego popularnego języka (także dla JS, więc klienta możesz zrobić czysto przeglądarkowego i C++, jak promotor się uprze).

* P2P (brak centralnego serwera)

P2P ma kilka dodatkowych utrudnień:
 * trzeba rozwiązać problem dostarczenia wiadomości, gdy czasy pracy nadawcy i odbiorcy nie przecinają się (już to zauważyłeś, dobrze). Rozwiązaniem jest rozrzucenie komunikatu do kilku innych klientów - może któryś będzie działał jak pojawi się odbiorca. Odbiorca potem rozsyła potwierdzenie odbioru, który globalnie wipuje tą wiadomość z sieci. Warto dodać TTL, żeby nie zaśmiecać sieci, jak jakiś odbiorca się wypisze z sieci permanentnie.
 * P2P nie lubi mechanizmu NAT (brak NAT możesz przyjąć w założeniach pracy - jak prom się zgodzi. Jak nie, to potrzebujesz jakiegoś dodatkowego serwera np z protokołem STUN/TURN)


Jeżeli chodzi o sam transport danych między klientami, popatrz na bibliotekę libP2P. Daje ci ona bardzo dużo fajnych mechanizmów ułatwiających komunikację P2P (w tym NAT-traversal). Nad tym można zbudować bardzo ciekawy komunikator pracujący bez serwera centralnego. Dodatkowym mykiem jest to, że jest implementacja lipP2P w JS - może działać całkowicie w przeglądarce.

Niezależnie od topologii - jak chodzi o zabezpieczanie samych wiadomości (kryptografia end-to-end), popatrz na protokół OTR (używane np w Jabberze) oraz na implementację w kliencie Signala (mechanizm double-ratchet)

[1709]

... użytkownicy mogą uruchamiać aplikacje o różnych godzinach  więc wiadomość nie zostanie dostarczona.

Z teoretycznego punktu widzenia ... Wiadomość może czekać w kolejce, aż obaj użytkownicy będą dostępni w tym samym czasie.
I nie potrzebny do tego jest żaden serwer pośredniczący.
Aplikacja może być wyłączona, więc wiadomości powinny być gdzieś zapisane. ( np. w pliku )
Duże ilości " danych " przechowuje się w bazach danych ze względu na szybkość zapisu i odczytu. ( np. SQLite )
Niektóre pierwsze komunikatory były proste
- bez baz danych
- bez szyfrowania,
- bez " optymalizacji " np. ograniczonej ilości wyświetlanych treści w danej chwili.
z czasem je ulepszano.

Można zrobić więcej, ale jest to kwestia nabytej umiejętności lub czasu.

Komunikator z serwerem pośredniczącym oczywiście jest bardziej złożony.
Najpopularniejsze to " czaty " / komunikatory na stronie internetowej.
Aplikacja zewnętrzna np. na telefonie loguje się, później pobiera lub wysyła treści,
oraz wyświetla treść w aplikacji.
Niektórzy upubliczniają własne API dla programistów do serwera pośredniczącego,
 aby stworzyć własną aplikację np. na telefon do ich serwisu.

[mathiass213]

Dzięki wielkie za pomoc na pewno będę się odzywał jeszcze w tym temacie jak będę miał do was pytania odnośnie budowy i zabezpieczania programu.

[Paweł Kraszewski]

Dzięki wielkie za pomoc na pewno będę się odzywał jeszcze w tym temacie jak będę miał do was pytania odnośnie budowy i zabezpieczania programu.

Jak będziesz miał potrzebę komunikacji poza forum, wyślij wiadomość przez "kopertkę" pod moim ID. Nie napiszę systemu za ciebie, ale mogę podpowiedzieć narzędzia, protokoły czy biblioteki i ewentualnie rzucić okiem na założenia, implementację i dokumentację, czy nie ma jakiś oczywistych fuckupów.

[mathiass213]

Hejka w swoim programie natrafiłem na problem z zarządzaniem efektywnym pamięcią odbieranych danych od soketa.
Omówienie problemu: Po nawiązaniu sesji użytkownik wysłane dane gdzie odbierane są po stronie bufora danych na sokecie.
Dane muszą zostać zinterpretowane zanim zostanie bufor danych opróżniony i będzie mógł odebrać nowe wiadomości.
Co stanowi dany problem.
Moim przykładowym rozwiązaniem jest stała pamięć zalakowana dla konkretnych komunikatów ale występuje problem z podejściem wielowątkowym co jest dla mnie ogromny wyzwaniem, moim innym rozwiązaniem danego problemu jest że każda sesja będzie miała swój przydział pamięci uzyska adres do konkretnej pamięci o danym zakresie co ułatwi mi zarządzaniem. Połączenie użytkownika i serwera nie będzie trwałe.
Jeżeli macie jakieś inne ciekawe rozwiązanie danego problemu chętnie je usłyszę albo jakieś rady

[Paweł Kraszewski]

problem z zarządzaniem efektywnym pamięcią

:] Witaj w klubie.

1. W jakim języku to w końcu piszesz? I na jaki OS?
2. Czy używasz jakiegoś wyżej-poziomowego narzędzia do socketów? (np z Boosta, jeżeli C++) Czy z surowych socketów systemu? Jaki protokół? TCP? UDP?

W takich rozwiązaniach - jeżeli nie wchodzisz w asynca (jak robi to np. nginx) i pracujesz na protokole połączeniowym - robisz wątek na połączonego klienta i wtedy powinieneś nadążać z czytaniem i interpretacją pakietów. Przydatny jest tu model aktora - jeden klient - jeden (albo dwa - jeden odbiorczy, jeden nadawczy) aktory, komunikacja między nimi przez komunikaty. Dla C++ na przykład The C++ Actor Framework.
Użycie aktorów z przesyłaniem komunikatów bardzo upraszcza model wielowątkowy (nie ma potrzeby ręcznych blokad czy globalnej synchronizacji).

Od lat pracuję na modelu aktora (w Erlangu co prawda) - świetnie się sprawdza w systemach P2P i klient-serwer.

[mathiass213]

Piszę program w C++ wykorzystując bibliotekę Boosta.
Chciałbym żeby serwer był postawiony na Linuxie większa wydajność i zabezpieczenia serwera itp ale na razie testuje wszystko na windowsie, aplikacja klienta ma być na dowolne środowisku wiem że to łatwo się mówi i stanowi wiele problemów.Na razie jestem na etapie "tworzę serwer echo"  gdzie będę odbierał komunikaty użytkowników opakowane w moją strukturę danych w postaci bajtów co umożliwi mi łatwiejsze zarządzanie nimi, Każda wiadomość będzie posiadała order  odpowiedzialny za wykonywanie konkretnej czynności z danymi.Protokół jaki używam jest na razie tcp ale to będzie zależne od użytkownika projektu itp .
Na każdą wiadomość użytkownika będzie zwracana wiadomość potwierdzająca odpowiedz serwera . Sesje użytkownika po dostarczeniu wiadomości będą zamykane.

[Paweł Kraszewski]

OK. To teraz pytanie do Ciebie - jak dużo własnego kodu musi być w pracy (tj rozumiem, że nie gotowy komunikator - ale może na przykład jakieś frameworki typowo sieciowe). Jeżeli tak, popatrz na gRPC.

* Format transmisji opisujesz plikiem tekstowym (format ProtoBuf).
* Na podstawie pliku generowane są:
  - Serializator i deserializator danych (nie musisz martwić się o format danych "na drucie")
  - Szablon serwera (klasa abstrakcyjna)
  - Szablon klienta (klasa abstrakcyjna)

Plusy gRPC/PB są takie:
* klient i serwer mogą być w różnych językach. Na przykład serwer w C++ i klienci w JS są możliwym rozwiązaniem.
* nie musisz bawić się w samodzielne pisanie obsługi sieci
* W przeciwieństwie do innych standardowych RPCów (REST, XML, itp), gRPC obsługuje funkcje przyjmujące i zwracające strumień wiadomości (nie tylko "one shot").
* Łatwo się aktualizuje protokół do nowych funkcji.

Jeżeli gRPC jest zbyt wysokopoziomowe/za bardzo "wszystkomający", popatrz na przykład na kombinację ZeroMQ do transmisji (AZMQ spina to z Boostem, ciebie najprawdopodobniej zainteresuje wzorzec PUB-SUB) i jakiegoś kodeka JSON/BSON/MsgPack do danych "na drucie".

EDIT: w dokumentacji Boosta masz gotowy przykład chatu.

[mathiass213]

Przepraszam że tak późno odpowiadam. Hejka ja to traktuje jako projekt do nauki rozumie, że najlepszym rozwiązaniem było najprostszy gotowy komunikator online ale czym więcej zagłębiam się w to tym więcej napotykam problemów i tematów do rozwinięcia i coraz bardziej widzę, że do programowania się nie nadaje....
Co do ilości kodu na pewno nie chciałbym tworzyć wyglądu edytora ale to pewnie jeszcze będzie zależeć od promotora.