struct A {
T a, b;
};
Czy istnieje struktura danych, która pozwoli trzymać obiekty typu A i wyszukiwać w niej szybko (czas stały, ewentualnie O(log2(n))) zarówno po A::a jak i A::b? Mógłbym użyć std::unordered_map ale wtedy musiałbym wybrać, co będzie hashowane, czyli key_type po którym będę mógł szybko szukać, zatem nie chodzi o to.
Może powiedz lepiej, do czego tego potrzebujesz/co chcesz osiągnąć.
Może coś z rodzaju Boost.MultiIndex?
A czemu nie dwie mapy T->struct A*?
Albo mapa T->struct A która ładuje daną strukturę dla obu wartości klucza do mapy (bo nie napisałeś nic o unikalności tych pól)?
Pola będą unikalne. Myślałem o takim rozwiązaniu, niestety nie mogę sobie pozwolić na podwojenie ilości potrzebnej pamięci. Rozwiązałem to inaczej - jest brzydko, ale wydajnie. Da sie przeżyć. Natomiast Boost.MultiIndex niedługo się zainteresuję. Po części rozwiązywałoby mój problem.
@Shalom @spartanPAGE @Patryk27 wołam bo może myślicie, że problem w 100% rozwiązany ;p
Tłumaczę use case:
tworzę serwer na którym ma działać giełda. Tradycyjnie - jest rejestracja, sprzedaż, kupno, inne takie. Wszystko działa na Boost.Asio. Zastanawiam się teraz nad zaprojektowanie bazy danych userów. Niestety nie mam w tym dużego doświadczenia. Moje pomysły:
Tutaj pojawia się problem. Logowanie użytkownika to komenda login <username> <password>. Po niej szukam usera w bazie danych, zapisuje jego aktualne ip. Każde kolejne komendy to np sell <price> <amount>. Teraz wyszukuje użytkownika po aktualnym adresie ip (dodatkowo musi być zalogowany - trzymam zmienną bool logged_on) i wykonuje komendę. Wszystko jest szyfrowane RSA i podpisane ed25519.
Jakieś pomysły? Najbardziej zależy mi na bezpieczeństwie. Właściwie nie wiem jak to ma być do końca zrobione. Tak jak mówiłem - to moja pierwsza styczność z projektowaniem serwera i bazy danych w C++.
Słabe. A jak będzie 2 userów z tym samym IP bo są za NATem to co? Mogiła? :D Jeśli już to musisz trzymać sesję uzytkownika jakoś unikalnie. Jak oni sie komunikują? Socketami? To musisz przy logowaniu tworzyć sobie jakiś wątek który trzyma ten socket + info o tym jaki to użytkownik i jak z socketu poleci sell to sprzedaje dla tego użytkownika.
I nadal nie rozumiem po co ci ta mapa jest ;]
Myślałem o dodaniu identyfikatora sesji, tu masz racje.
Każdą sesję mam trzymać w osobnym wątku? Jakoś nie widzę tego.
"Mapa" potrzebna oczywiście do wyszukiwania usera w bazie danych.
Mam jeszcze pomysł taki, żeby user za każdym razem wysyłał mi swój nick. Może to by pomogło jakoś.
To ja nadal nie ogarniam. User ma dwa loginy czy co? User podaje info logowania. Hashujesz hasło a potem jeśli to SQL to robisz zwykłe zapytanie. Jeśli masz to w mapie to dla mnie to ma być mapa String->User, wyciągam z niej usera po loginie i jeśli istnieje to porównuje hashe haseł. Gdzie tu miejsce na jakieś multimapy i inne cuda?
Nie musisz trzymać każej sesji w osobnym wątku, ale nie napisałeś w jaki sposób to działa więc wróżę z fusów. Musisz jakoś identyfikować od kogo idą dane ale jeśli ty to czytasz z jakiegoś bezstanowego serwisu to user musiałby cały czas nadawać swoje session ID. Ale jeśli wszystko szyfrujesz to może to nie aż taki problem.
edit: jasne, niech wysyła login. Daj mi potem link do tej aplikacji i będę sprzedawał jako kulczyk wysyłając jego nick w wiadomościach :D Jeśli juz to losowe session ID, a najlepiej to w ogóle jakieś zmienne session ID.
No tak średnio bym powiedział, chyba, że podpiszesz mi to kluczem prywatnym kulczyka ;D
EDIT:
No to w takim razie możesz wysyłać ten login od biedy bo rozumiem że po loginie wyciągasz klucz publiczny, deszyfrujesz wiadomość i wykonujesz akcje? W takim razie w ogóle nie widzę powodu jakiegoś logowania. Jak ktos poda lewy nick to deszyfrowanie RSA sie nie powiedzie i odrzucisz takie żądanie. A jeśli podpisal wiadomość kluczem prywatnym to już wiesz kim jest i hasła nie są potrzebne. Oczywiście masz tu spore ryzyko jakiegoś DoS ale takie życie.
No to jest fajne. I wtedy szybkie szukanie po username i już. No fajne, fajne.