Biblioteka sieciowa w C++

Odpowiedz Nowy wątek
2019-09-08 12:14
5

Hej. Napisałem łatwą w użyciu bibliotekę sieciową w C++. Na razie wsprarcie tylko pod linux (wsparcie pod windows jest planowane).
Bibliotekę będę używał głównie do własnych narzędzi adhoc, planuję też napisać "nad nią" serwer http. sprawdzić wydajność.
Dajcie znać co myślicie o kodzie / projekcie. Link do repo: https://github.com/lukascode/socket-nano.

Pozostało 580 znaków

2019-10-08 19:15
0

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?

edytowany 1x, ostatnio: lookacode1, 2019-10-08 20:10

Pozostało 580 znaków

2019-10-08 20:01
0

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).

Pozostało 580 znaków

2019-10-08 20:51
0

@_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.

Pozostało 580 znaków

2019-10-08 21:26
0

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.

edytowany 2x, ostatnio: _0x666_, 2019-10-08 22:28

Pozostało 580 znaków

2019-10-08 21:48
0

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.

Pozostało 580 znaków

2019-10-08 22:20
0

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.

edytowany 1x, ostatnio: _0x666_, 2019-10-08 22:28

Pozostało 580 znaków

2019-10-08 22:47
0

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);
}

Pozostało 580 znaków

2019-10-09 00:04
0

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.

Pozostało 580 znaków

2019-10-09 00:37
0

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.

edytowany 3x, ostatnio: lookacode1, 2019-10-09 00:46

Pozostało 580 znaków

2019-10-09 11:08
0

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).

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0