Biblioteka sieciowa w C++

W przykładzie jest jawnie użyty operator new: new HttpRequestHandler!
We współczesnym C++ jest to niezalecane.

Funkcjonalność HTTP, w której trzeba podać w całości nagłówki i body nie jest zbyt poręczna.

Tyle patrząc tylko na stronę główną. Do środka może jeszcze zajrzę.

Przeglądnąłem na szybko.
IMHO słabo, że nie uzyłeś poll/epoll/select tylko bazujesz na callach blokujących. Fajnie by też było dołożyć obsługę wielu procesów, a nie tylko wątków.

alagner napisał(a):

Przeglądnąłem na szybko.
IMHO słabo, że nie uzyłeś poll/epoll/select tylko bazujesz na callach blokujących. Fajnie by też było dołożyć obsługę wielu procesów, a nie tylko wątków.

Na razie bazuje na callach blokujących. Łatwiej przerzucić odpowiedzialność obsługi połączenia na użytkownika biblioteki, który zaimplementuje TcpConnectionHandler
i obsluga zostanie wystartowana w nowym wątku z puli. Do czego miałaby służyć obsługa wielu procesów?

Z tymi procesami jest trochę kwestia przyjętej konwencji i tego co Ci wyjdzie z pomiarów. Na linuxie imho wieloprocesowość jest łatwiejsza w utrzymywaniu, bo operujesz jednak na osobnych przestrzeniach adresowych i nie ryzykujesz, że weźmiesz nie swój zasób, bo współdzielone jest tylko to, co explicite takim uczynisz. Aczkolwiek może to mój osobisty przechył po latach programowania w C.
Do poczytania https://elinux.org/images/1/1c/Ben-Yossef-GoodBadUgly.pdf

@alagner wydaje mi się, że wsparcie dla wątków jest wystarczające, czy jest jakaś biblioteka sieciowa, która daje wsparcie procesów?

Jakieś rady co można by było ulepszyć?

Tak pobieżnie. Nie używaj surowych wskaźników, używaj deklaracji zapowiadających, dla typów integralnych masz do dyspozycji aliasy, np std::atomic_bool. Twój thread pool jest, hmm, taki sobie. Użyj może na początku jakiejś zgrabnej implementacji, np CTPL.

Twój thread pool jest, hmm, taki sobie. Użyj może na początku jakiejś zgrabnej implementacji, np CTPL.

No nwm ja przynajmniej mam jakieś testy swojego, chyba zostane przy swoim.

Zmieniłem surowe pointery na smart. Wygląda to dużo lepiej. Jeszcze jakieś rady / sugestie?
Czy powinienem wrzucić bibliotekę w przestrzeń nazw? Czy nazewnictwo jest ok?

Kopiuj

void Socket::SendAll(const std::string &data)
{
    SendAll(std::vector<uint8_t>(data.begin(), data.end()));
}

Po co ten vector, skoro masz wersję funkcji przyjmujący wskaźnik i ilość bajtów?

Nie jestem też przekonany do modelu obsługi połączeń. Teraz jest tak, że połączenie na czas obsługi zajmuje wątek, co jest słabym rozwiązaniem, bo dobrze napisany serwer powinien być w stanie obsługiwać "jednocześnie" wiele połączeń na jednym wątku.

Po co ten vector, skoro masz wersję funkcji przyjmujący wskaźnik i ilość bajtów?

Faktycznie zmienię to.

Nie jestem też przekonany do modelu obsługi połączeń. Teraz jest tak, że połączenie na czas obsługi zajmuje wątek, co jest słabym rozwiązaniem, bo dobrze napisany serwer powinien być w stanie obsługiwać "jednocześnie" wiele połączeń na jednym wątku.

Tylko, że to wymaga raczej użycia non-blocking io. Ja na razie wspieram tylko synchroniczne io.
Tomcat jest przykładem gdzie jest thread per request.
W synchronicznym io łatwiej było przerzucić odpowiedzialność obsługi połączenia na klienta biblioteki, która
odbywa się w jednym wątku. Masz jakiś pomysł aby zrobić to asynchronicznie?

Funkcją select możesz sprawdzać, czy coś jest w sockecie do przeczytania, zatem nie musisz mieć trybu nieblokującego. Teraz task po wykonaniu zadania jest wyrzucany z kolejki, co oznacza (w pewnym sensie) koniec połączenia. Myślę, że mógłbyś zrobić tak, że wyrzucany z kolejki jest dopiero wtedy, gdy np. zwróci wartość mówiąca zakończenie obsługi połączenia. To oznacza, że HandleConnection będzie wywoływana wielokrotnie, co da możliwość wykonywania obsługi na raty (np. ściąganie/wysyłanie ogromnego pliku).

@_0x666_: W założeniu w HandleConnection ma być logika obsługi polączenia dostarczona przez klienta biblioteki.
W jaki sposób "wracać" do tej metody i do kontekstu w jakim się znajduje na jednym połączeniu?
W zasadzie w HandleConnection klient może pisać i czytać z socketu wykorzystując np. RecvAll, SendAll,
które są blokujące więc sprowadza się to do tego, że gdy HandleConnection się skończy to połączenie się kończy.

W jaki sposób "wracać" do tej metody i do kontekstu w jakim się znajduje na jednym połączeniu?

Kontekst zapewnia obiekt zapewniony przez klienta.

które są blokujące więc sprowadza się to do tego, że gdy HandleConnection się skończy to połączenie się kończy.

No niekoniecznie. Na przykład:

• RecvUntil odbierasz nagłówek zapytania HTTP.
• SendAll wysyłasz nagłówek odpowiedzi
• w pozostałych wywołaniach HandleConnection wysyłasz zawartość po np. 512KB.

W ten sposób nie blokujesz wątku, bo wysyłasz zawartość po kawałku i jeden wątek jest w stanie obsługiwać kilka(naście) połączeń na raz.

powinieneś zrobić metodę Recv, która czyta tyle, ile w danej chwili może

Czyli wywołując Recv(512 * 1024); powinna skończyć działanie jeśli przyszło na razie tylko 128B?

Czyli TcpServer powinien sprawdzać na każdym sockecie czy są już dane, jeżeli tak to wywołać kolejny raz HandleConnection?
Co w przypadku gdy wywołam blokujące SendAll a w tym czasie coś pojawiło się na sockecie i dla danego obiektu klienta w tym samym
czasie będą działały 2 metody HandleConnection? Trzeba pewnie by było synchronizować.
Wydaje mi się też, że logika klienta w HandleConnection musiałaby być bardziej zawiła chociaż Twój pomysł wydaję się mieć sens jeżeli go dobrze rozumiem.

Czyli wywołując Recv(512 * 1024); powinna skończyć działanie jeśli przyszło na razie tylko 128B?

Tak. Nie powinien być też blokujący.

Czyli TcpServer powinien sprawdzać na każdym sockecie czy są już dane, jeżeli tak to wywołać kolejny raz HandleConnection?

Wtedy metoda powinna się nazywać onRecvData lub coś w tym stylu. A co z wysyłaniem?

Trzeba pewnie by było synchronizować.

Nie, HandleConnection w danej chwili może wywołać tylko jeden wątek, zatem synchronizacja odbywałaby się na poziomie puli wątków - wątek bierze z kolejki task, wykonuje go, i z powrotem wstawia do kolejki (chyba że dostanie sygnał, że już nie trzeba).

P.S. wcześniej w punktach podałem przykład bardziej dla klienta niż serwera, dlatego je przeedytowałem.

A co z wysyłaniem?

Wysyłanie chyba blokujące?

chyba że dostanie sygnał, że już nie trzeba

W postaci wartości zwrotnej? upraszczając np.

status = task();
if(status == CONTINUE) {
   submitTask(task);
}

Wysyłanie chyba blokujące?

To było pytanie retoryczne ;) Chodziło mi o to, że HandleConnection nie może być wywoływane tylko wtedy, gdy jakieś dane przyjdą od klienta.

W postaci wartości zwrotnej?

Tak.

Chodziło mi o to, że HandleConnection nie może być wywoływane tylko wtedy, gdy jakieś dane przyjdą od klienta.

Czemu?

Nwm czy dobrze rozumiem koncepcję, pokaże na przykładzie:

nbytes_to_read = 1024 * 1024; // download 1MB
std::string data;

HandleConnection()
{
        std::string recv_data = socket->Recv(nbytes_to_read - data.size()); // non blocking
        data += recv_data;
        if (data.size() < nbytes_to_read) {
             return CONTINUE;
        }
   
   // we have all data here
   saveAsFile(data);
   return TERMINATE;
}

Czyli ten kto pisze HandleConnection jest odpowiedzialny za zbieranie danych do kupy.
I właśnie trochę tego chciałem uniknąć RecvAll blokujące, której napisałem jest wygodniejsze,
od razu mamy tyle danych o ile prosiliśmy, z drugiej strony marnujemy zasoby.

Czemu?

Ponieważ serwer może wysyłać do klienta większy plik fragmentami, więc potrzebne będzie wielokrotne wywołanie HandleConnection. Dlatego wywołanie tej metody nie może być uzależnione od tego, czy w sockecie jest coś do przeczytania.

pokaże na przykładzie:

No mniej więcej.

I właśnie trochę tego chciałem uniknąć RecvAll blokujące, której napisałem jest wygodniejsze,

Owszem, wygodniejsze. I niewątpliwie sprawdzi się po stronie klienta. Ale piszemy o serwerze, który potencjalnie ma obsługiwać dużą ilość połączeń naraz, bez angażowania ogromnej ilości wątków (bo to zżera zasoby i spowalnia system). Możesz spróbować zrobić metody RecvAll, RecvUntil i SendAll w klasie TcpConnectionHandler, które będą wykonywać swoją robotę na raty, a zakończenie odczytu/wysyłania będą zgłaszać wywołując podany w parametrze handler (w boost::asio jest tak zrobione).