Dynamicznie wielkości boost :: asio :: bufor

Question

Czytam z boost::asio::ip::udp::socket tak:

using boost::asio::ip::udp; 

// ... 

char recv_buf[128]; 
udp::endpoint sender_endpoint; 
size_t len = socket.receive_from(boost::asio::buffer(recv_buf), sender_endpoint); 

Teraz to działa perfekcyjnie, ale maksymalna ilość znaków, które jestem w stanie odbierać teraz 127. Jednakże mam do czynienia z pewnym problemem, ponieważ muszę zaakceptować pewne dane wejściowe, których długość może się znacznie różnić (na przykład nie ma dobrze określonej długości z prefiksowanymi nagłówkami). Rozwiązaniem tego problemu byłby dynamicznie rozwijający się bufor, taki jak wektor. Czy możliwe jest utworzenie dynamicznie rozwijającego się obiektu boost::asio::buffer, aby zaakceptować (teoretyczne) dane wejściowe i zapisać je w kontenerze?

Answer 1

Rozmiar datagramu UDP nie zmienia się tak bardzo: nigdy nie będzie większy niż 65535, pozostawiając miejsce dla 65 527 bajtów danych po 8-bajtowym nagłówku.

Answer 2

Wygląda na to, że nie ma żadnego przepisu dotyczącego dynamicznego rozmiaru. I ma sens, że nie byłoby. Pomyśl o tym, co musiałoby się wydarzyć:

• Pojedyncza datagram UDP mogą być odbierane tylko raz, a jednocześnie, w związku z tym:
• bufor podane do wywołania systemowego niskiego poziomu musi być wystarczająco duża dla największa ważna wiadomość, więc, aby była skuteczna, bufor musi być przydzielony z góry przez dzwoniącego.

Nie ma sensu, aby dostępny był bufor o dynamicznym rozmiarze. Jak wskazuje Cubbi, datagramy UDP mają w każdym razie niewielki maksymalny rozmiar, więc po prostu ustaw bufor tak duży, jak największa poprawna wiadomość w twoim systemie i zrób z nim.

Answer 3

Jeśli używasz mniejszych buforów, możesz je łatwo połączyć za pomocą koncepcji * BufferSequences. Na przykład można przekazać MutableBufferSequence , aby zaakceptować dane z wywołania read (2) lub przekazać ConstBufferSequence dla listy buforów, które zamierzasz napisać (2). Mimo to, zalecam używanie pojedynczego bufora w każdym kierunku, ponieważ ma on tendencję do upraszczania kodu (choć nie zawsze jest to możliwe).