jam231
commented
10 years ago "Prototypy" dumnie brzmiały, ale niestety Qt narzuca niefajne ograniczenia związane z wielowątkowością. Jednym z tych ograniczeniem jest to, że podobno QTcpSocket może być wykorzystywany tylko w wątku w którym został stworzony - na szczęście to nie do końca prawda i dało mi się to obejść kosztem ręcznego [ ] przerzucania polaczenia do kolejnych wątków. Niestety specyfika tego mechanizmu [ ] powoduje, że używanie QtConcurrent::run, future'ów etc. jest niemożliwe. To bardzo ogranicza pole manewru.
To co jest teraz, tj. wątki: Master Server LoginServer, Trading Server^n, Event Server i Notifications Server wydaje mi się najsensownejsze jako, że funkcjonalność jest całkiem dobrze odseparowana (boli mnie to, że Login Server wie o Master Serverze, ale [*] ). To, że jest jeden Login Server, a n Trading Serverów wynka z tego, że Login Server tylko odpowiada za logowanie i rejestracji kont. Można by się zastanowić nad jakimś prostym zabezpieczniem przed throttlingiem przez niewydarzonych agentow, np. zliczaniem wysłanych wiadomości i po przekroczeniu na czasową ban listę.
Btw Qt sie nie nadaje do pisania tego typu aplikacji. Prognozuje, ze 5k agentów (bez sztucznego ograniczania rps agenta) przy latency 100-200 ms to górne ograniczenie przy przyzwoicie zoptymalizowanej bazie. Niestety Qt korzysta z select/poll i nie ma planów by dodać epoll/kqueue,
Cytacik z listy mailingowej:
I've talked to kernel developers and they tell me that epoll is not meant for generic, graphical user applications with a handful of file descriptors. It's meant for large server applications with hundreds of file descriptors or more.
[*] obj->moveToThread(T1) można jedynie wywołać z wątku do którego przynależy obiekt obj.
Zastanowić się nad designem i zrobić prototyp(y).