Programowanie > C/C++
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:
--- Cytuj ---Szybko mnie przejrzałeś.
--- Koniec cytatu ---
8 lat dydaktyki robi swoje...
--- Cytuj ---Co do 3 pytania
--- Koniec cytatu ---
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:
--- Cytuj ---... użytkownicy mogą uruchamiać aplikacje o różnych godzinach więc wiadomość nie zostanie dostarczona.
--- Koniec cytatu ---
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.
Nawigacja
[#] Następna strona
Idź do wersji pełnej