🚀 go-pugleaf

Borneq <borneq@antyspam.hidden.pl> wrote:

> Chcę zrobić komunikację między dwoma procesami na localhoscie przy 
> użyciu boost.asio. Po TCP na Windows szybko idzie ale na linuksie są 
> przestoje.

Zastanowiłbym się dlaczego. Wiesz co to algorytm Nagle'a i TCP_NODELAY?

-- 
[ Email: a@b a=grp b=chmurka.net ]
[ Web:   http://www.chmurka.net/ ]

W dniu 06.09.2017 o 13:31, Adam Wysocki pisze:
> Borneq <borneq@antyspam.hidden.pl> wrote:
> 
>> Chcę zrobić komunikację między dwoma procesami na localhoscie przy
>> użyciu boost.asio. Po TCP na Windows szybko idzie ale na linuksie są
>> przestoje.
> 
> Zastanowiłbym się dlaczego. Wiesz co to algorytm Nagle'a i TCP_NODELAY?
> 
Problemem wydaje się wymiana danych każdorazowo przy przesyłaniu 
pakietu. To ma działać na localhost więc może jest 100% skuteczność 
doręczenia? Choć miło by było aby zadziałało również na komputerze zdalnym.
Działa tak, że w wątku głównym program komunikuje się w obie strony 
przez UDP. Dodatkowo jest wątek poganiający:
gdy przez dłuższy czas wątek główny czeka przed pobraniem bajtów, wątek 
wysyła "heartbeat" który też może nie dotrzeć, albo jego odpowiedź może 
nie dotrzeć. Serwer wysyła odpowiedź i różne możliwości:
- wysłany bo komunikat nie doszedł do serwera - wymagana ponowna akcja
- wysłany bo komunikat powrotny nie doszedł do klienta - zwraca starą 
odpowiedź.
- ale jeszcze komplikuje - wysłany komunikat, ale było bez błędów w 
komunikacji, tylko po prostu serwer wykonywał długą procedurę i odeśle 
jak tylko się zakończy.

W dniu 06.09.2017 o 13:31, Adam Wysocki pisze:
> Zastanowiłbym się dlaczego. Wiesz co to algorytm Nagle'a i TCP_NODELAY?

A może zająć się tym lepiej? Tylko jak w boost.asio to ustawić?

W dniu 06.09.2017 o 13:31, Adam Wysocki pisze:
> Zastanowiłbym się dlaczego. Wiesz co to algorytm Nagle'a i TCP_NODELAY?

TCP_NODELAY nie pomógł tcp::no_delay option(true);

Borneq pisze:
> Chcę zrobić komunikację między dwoma procesami na localhoscie przy 
> użyciu boost.asio. Po TCP na Windows szybko idzie ale na linuksie są 
> przestoje. Chcę zrobić UDP, ale tak, by nie czekać na odpowiedź w 
> nieskończoność ale gdy nie otrzymam odpowiedzi wysłać ponowienie. Czy 
Gdyby problemy występowały pod Windows niewiele bym mógł pomóc,
ale pod Linux/UNIX istnieje bogactwo narzędzi w postaci:
netstat, tcpdump, ba nawet strace (sys call trace)
(z opcją wyświetlania czasu przed każdym syscall)
tcpdump również wyświetla znacznik czasu przy każdym pakiecie,
więc problem można zdiagnozować bardzo dokładnie.
Co prawda za mało danych, by ustalić dokładnie problem,
być może dane wysyłane są bajt po bajcie.
Proszę sprawdzić: SO_SNDBUF oraz SO_RCVBUF
i podzielić się rezultatem, być może dane
są buforowane przed wysłaniem.

> możliwe jest to przy użyciu boost.asio?

W dniu 06.09.2017 o 19:29, PawelS cbrbob(at)wbcd(dot)pl pisze:
> Proszę sprawdzić: SO_SNDBUF oraz SO_RCVBUF
> i podzielić się rezultatem, być może dane
> są buforowane przed wysłaniem.

Udało się zrobić na UDP. Ma ograniczenia 1 KB na pakiet, ale ja będę 
dostawał się jeszcze do mniejszych kawałków danych

On Wednesday, September 6, 2017 at 6:48:30 PM UTC+2, Borneq wrote:
> Problemem wydaje się wymiana danych każdorazowo przy przesyłaniu 
> pakietu. To ma działać na localhost więc może jest 100% skuteczność 
> doręczenia?

Jak ma działać na lokalnej maszynie, to czemu nie użyjesz np. pamięci
dzielonej albo kolejek nazwanych (named pipes)?

w.

W dniu 07.09.2017 o 12:18, Wojciech Muła pisze:
> Jak ma działać na lokalnej maszynie, to czemu nie użyjesz np. pamięci
> dzielonej albo kolejek nazwanych (named pipes)?

Chciałem użyć boost.asio, tam były przykłady na echo. Pamięć dzielona 
może dobre rozwiązanie, ale jak po władowaniu do niej uruchomić drugą 
stronę. Może się przydać do UDP, wtedy wysyłał bym mały komunikat i w 
pamięci dzielonej miałbym więcej danych.

On Thursday, September 7, 2017 at 10:25:02 PM UTC+2, Borneq wrote:
> W dniu 07.09.2017 o 12:18, Wojciech Muła pisze:
> > Jak ma działać na lokalnej maszynie, to czemu nie użyjesz np. pamięci
> > dzielonej albo kolejek nazwanych (named pipes)?
> 
> Chciałem użyć boost.asio, tam były przykłady na echo. Pamięć dzielona 
> może dobre rozwiązanie, ale jak po władowaniu do niej uruchomić drugą 
> stronę. 
Rozumiem drugi program. Do tego celu służą semafory, generalnie 
synchronizacja. 
Pozdrawiam

On 9/7/2017 22:25, Borneq wrote:
> W dniu 07.09.2017 o 12:18, Wojciech Muła pisze:
>> Jak ma działać na lokalnej maszynie, to czemu nie użyjesz np. pamięci
>> dzielonej albo kolejek nazwanych (named pipes)?
> 
> Chciałem użyć boost.asio, tam były przykłady na echo. Pamięć dzielona 
> może dobre rozwiązanie, ale jak po władowaniu do niej uruchomić drugą 
> stronę.

Boost.Interprocess do tego sluzy -- patrz ponizszy prosty przyklad (kod 
sluzy zarowno jako proces-serwer i proces-klient, ale trywialnie prosty 
do rozdzielenia):

http://www.boost.org/doc/libs/release/doc/html/interprocess/sharedmemorybetweenprocesses.html#interprocess.sharedmemorybetweenprocesses.sharedmemory.shared_memory_a_simple_example

Dokumentacja:
https://theboostcpplibraries.com/boost.interprocess
http://www.boost.org/doc/libs/release/doc/html/interprocess.html

Jak chcesz komunikacje przez siec, to przyjrzabylm sie tez ZeroMQ.
"Hello World in C++"
client: http://zguide.zeromq.org/cpp:hwclient
server: http://zguide.zeromq.org/cpp:hwserver

Jest wybor C++ Bindings: http://zeromq.org/bindings:cpp
N.p., AZMQ Boost Asio + ZeroMQ: https://github.com/zeromq/azmq

Pozdrawiam,

Matt

Borneq pisze:
> W dniu 06.09.2017 o 19:29, PawelS cbrbob(at)wbcd(dot)pl pisze:
>> Proszę sprawdzić: SO_SNDBUF oraz SO_RCVBUF
>> i podzielić się rezultatem, być może dane
>> są buforowane przed wysłaniem.
> 
> Udało się zrobić na UDP. Ma ograniczenia 1 KB na pakiet, ale ja będę 
> dostawał się jeszcze do mniejszych kawałków danych
Czy mógłbyś nieco bardziej rozwinąć zdanie:
"Ma ograniczenia 1 KB na pakiet" ?
To chyba nie odnosi się do wielkości pakietu,
czy ilości danych, które można przesłać w UDP
(tak mam tu na myśli size_t len z deklaracji sendto()).
Z moich przeprowadzonych testów w praktyce
można wysłać i odebrać prawie 64kB (65536 Bajtów).
Oczywiście zależy to też od środowiska,
na FreeBSD napotkałem błąd przy wywoływaniu sendto()
przy ustawionej wielkości bufora bliskiej 65536 Bajtów
(nie pamiętam w tej chwili kodu błędu).

W dniu 11.09.2017 o 19:56, PawelS cbrbob(at)wbcd(dot)pl pisze:
> Czy mógłbyś nieco bardziej rozwinąć zdanie:

> można wysłać i odebrać prawie 64kB (65536 Bajtów).
> Oczywiście zależy to też od środowiska,

Może ma 64 kilobajty w linuxie bo testowałem najpierw rozwiązanie pod 
Windows i tam zawieszał się ponad 1 kB.

On Monday, September 11, 2017 at 8:34:40 PM UTC+2, Borneq wrote:
> W dniu 11.09.2017 o 19:56, PawelS cbrbob(at)wbcd(dot)pl pisze:
> > Czy mógłbyś nieco bardziej rozwinąć zdanie:
> 
> > można wysłać i odebrać prawie 64kB (65536 Bajtów).
> > Oczywiście zależy to też od środowiska,
> 
> Może ma 64 kilobajty w linuxie bo testowałem najpierw rozwiązanie pod 
> Windows i tam zawieszał się ponad 1 kB.

Ile czasu zyskujecie gdy przejdziecie z TCP na UDP?
Pozdrawiam

W dniu 12.09.2017 o 14:47, M.M. pisze:
> Ile czasu zyskujecie gdy przejdziecie z TCP na UDP?
> Pozdrawiam

Bardzo dużo, przynajmniej rząd wielkości. Baza HBase zapisuje bardzo 
szybko, natomiast najdłużej trwało nawiązywanie połączenia tcp, tak że 
przez TCP prawie cały czas zużyty byłby na te połączenia.

W dniu wtorek, 5 września 2017 21:31:52 UTC+2 użytkownik Borneq napisał:
> Chcę zrobić komunikację między dwoma procesami na localhoscie przy 
> użyciu boost.asio. Po TCP na Windows szybko idzie ale na linuksie są 
> przestoje. Chcę zrobić UDP, ale tak, by nie czekać na odpowiedź w 
> nieskończoność ale gdy nie otrzymam odpowiedzi wysłać ponowienie. Czy 
> możliwe jest to przy użyciu boost.asio?

Gdzieś pod skórą czuję, że próbujesz się do czegoś zabrać od złej strony. Z czego wynika wymóg niskich latencji? Generalnie w przypadku zaawansowanych aplikacji serwerowych w grę wchodzą modyfikacje kernela systemu (mówię o BSD & Linux) - można na tym sporo ugrać (rzędy kilkukrotnego zmniejszenia latencji).

Jednak w tym wypadku uważam, że IPC rozwiąże Twój problem.

W dniu 15.09.2017 o 14:28, dawid.bautsch@gmail.com pisze:
> Jednak w tym wypadku uważam, że IPC rozwiąże Twój problem.

Jakie funkcje można wykorzystać? Obawiam się że UDP tez może być niezbyt 
szybkie, bo odczyt może być dopiero gdy system przerzuci się na inny 
proces, a nie od razu.

Borneq pisze:
> W dniu 12.09.2017 o 14:47, M.M. pisze:
>> Ile czasu zyskujecie gdy przejdziecie z TCP na UDP?
>> Pozdrawiam
> 
> Bardzo dużo, przynajmniej rząd wielkości. Baza HBase zapisuje bardzo 
> szybko, natomiast najdłużej trwało nawiązywanie połączenia tcp, tak że 
> przez TCP prawie cały czas zużyty byłby na te połączenia.

Nie znam szczegółów działania komunikacji, ale skoro
nawiązywanie połączenia tcp było
czasowo kosztowne to takim razie zapytam:
w jakim celu połączenie po nawiązaniu było zamykane ?
Może wystarczy nawiązać połączenie i utrzymywać je (keep-alive).

W dniu 16.09.2017 o 10:17, PawelS cbrbob(at)wbcd(dot)pl pisze:
> Nie znam szczegółów działania komunikacji, ale skoro
> nawiązywanie połączenia tcp było
> czasowo kosztowne to takim razie zapytam:
> w jakim celu połączenie po nawiązaniu było zamykane ?
> Może wystarczy nawiązać połączenie i utrzymywać je (keep-alive).

Nie zamykałem, używałem komunikacji synchronicznej z biblioteki 
boost.asio, z przykładu na echo.

On Friday, September 15, 2017 at 2:28:53 PM UTC+2, dawid....@gmail.com wrote:
> W dniu wtorek, 5 września 2017 21:31:52 UTC+2 użytkownik Borneq napisał:
> > Chcę zrobić komunikację między dwoma procesami na localhoscie przy 
> > użyciu boost.asio. Po TCP na Windows szybko idzie ale na linuksie są 
> > przestoje. Chcę zrobić UDP, ale tak, by nie czekać na odpowiedź w 
> > nieskończoność ale gdy nie otrzymam odpowiedzi wysłać ponowienie. Czy 
> > możliwe jest to przy użyciu boost.asio?
> 
> Generalnie w przypadku zaawansowanych aplikacji serwerowych w grę 
> wchodzą modyfikacje kernela systemu (mówię o BSD & Linux) - można na 
> tym sporo ugrać (rzędy kilkukrotnego zmniejszenia latencji).

A jeśli tak, to prawdopodobnie można taniej zakupić gotową łatkę na jądro 
systemu. Nie znam tematu, ale na chłopski rozum oszczędności mogą
wynikać chociażby na zmniejszeniu bezpieczeństwa systemu, bo w
konkretnej sytuacji system może być zabezpieczony w inny sposób; albo
dana cecha systemu w ogóle może nie być potrzebna. Kilka razy spotkałem 
się z sytuacją, w której poszukiwano programistów do pracy nad 
dostosowywaniem jądra systemu.

Pozdrawiam 

Borneq pisze:
> W dniu 16.09.2017 o 10:17, PawelS cbrbob(at)wbcd(dot)pl pisze:
>> Nie znam szczegółów działania komunikacji, ale skoro
>> nawiązywanie połączenia tcp było
>> czasowo kosztowne to takim razie zapytam:
>> w jakim celu połączenie po nawiązaniu było zamykane ?
>> Może wystarczy nawiązać połączenie i utrzymywać je (keep-alive).
> 
> Nie zamykałem, używałem komunikacji synchronicznej z biblioteki 
> boost.asio, z przykładu na echo.
W takim razie prawdopodobnie został użyty przykład,
bez dokładniejszego zrozumienia co przykład pokazuje
oraz jak działa biblioteka.
Gdyby faktycznie nastąpiło nawiązanie połączenia tcp,
które potem byłoby utrzymywane (keep-alive),
to nawet nie pojawiłaby się w ogóle myśl,
że nawiązywanie połączenia TCP jest bardzo kosztowne,
że o wiele szybciej dane można przesłać przy UDP.
Proszę mnie poprawić jeśli się mylę.

On Monday, September 18, 2017 at 6:52:32 PM UTC+2, PawelS cbrbob(at)wbcd(dot)pl wrote:
> Borneq pisze:
> > W dniu 16.09.2017 o 10:17, PawelS cbrbob(at)wbcd(dot)pl pisze:
> >> Nie znam szczegółów działania komunikacji, ale skoro
> >> nawiązywanie połączenia tcp było
> >> czasowo kosztowne to takim razie zapytam:
> >> w jakim celu połączenie po nawiązaniu było zamykane ?
> >> Może wystarczy nawiązać połączenie i utrzymywać je (keep-alive).
> > 
> > Nie zamykałem, używałem komunikacji synchronicznej z biblioteki 
> > boost.asio, z przykładu na echo.
> W takim razie prawdopodobnie został użyty przykład,
> bez dokładniejszego zrozumienia co przykład pokazuje
> oraz jak działa biblioteka.
> Gdyby faktycznie nastąpiło nawiązanie połączenia tcp,
> które potem byłoby utrzymywane (keep-alive),
> to nawet nie pojawiłaby się w ogóle myśl,
> że nawiązywanie połączenia TCP jest bardzo kosztowne,
> że o wiele szybciej dane można przesłać przy UDP.
> Proszę mnie poprawić jeśli się mylę.

Ja od początku uważam to samo, ale aplikacje komunikujące
się po gniazdkach piszę raz na kilka lat, nie jestem 
ekspertem. Po nawiązaniu połączenia (chyba) nie ma dużego 
narzutu na transmisję w porównaniu do udp.

Pozdrawiam

W dniu 08.09.2017 o 15:41, Matt D. pisze:
> Boost.Interprocess do tego sluzy -- patrz ponizszy prosty przyklad (kod 
> sluzy zarowno jako proces-serwer i proces-klient, ale trywialnie prosty 
> do rozdzielenia):
> 
> http://www.boost.org/doc/libs/release/doc/html/interprocess/sharedmemorybetweenprocesses.html#interprocess.sharedmemorybetweenprocesses.sharedmemory.shared_memory_a_simple_example 
> 

Czy wystarczająco szybki? Okazuje się że nie tylko TCP, ale i UDP jest 
za wolne na moje potrzeby, nie działa szybciej lokalnie niż jest 
ograniczone przez zmianę kontekstu procesu:
- klient pyta
- system przechodzi do serwera, który wykonuje
- system przechodzi do klienta z odpowiedzią

Co prawda na nowych Linuksach jest zegar nie 100 a 1000 MHz, ale i tak 
dłużej znacznie trwa operacja wymiany komunikatów UDP niż sama operacja 
zapisu.
Czy interprocess nie jest ograniczany takimi sprawami jak zmiana 
kontekstu? A jak działać na innej maszynie niż lokalny?

W dniu 08.09.2017 o 15:41, Matt D. pisze:
> http://www.boost.org/doc/libs/release/doc/html/interprocess/sharedmemorybetweenprocesses.html#interprocess.sharedmemorybetweenprocesses.sharedmemory.shared_memory_a_simple_example 
> 

Czy działając na jednym komputerze nie ma szans na szybszą odpowiedź aż 
systemowy sheduler przełączy najpierw z klienta na serwer a potem znowu 
na klienta?
Tak jest chyba z UDO a jak z boost.interprocess? też czekamy aż proces 
zwolni muteksa?
A jak gdy mamy nie na jednym komputerze a w sieci lokalnej?
W sieci lokalnej przesłanie całego megabajta trwa bardzo krótko. podczas 
gdy przełączanie się po każdym kawałku kilkuset bajtów trwało by długo.
Więc może serwer gromadziłby wiele pakietów klienta, nie odpowiadając po 
każdym?
Sytuacja jest taka: serwer zarządza bazą danych, zapis czy wyszukanie 
rekordu trwa błyskawicznie, zwłaszcza gdy nie trzeba się odwoływać do 
dysku a pobierać dane z cache pamięci. Teraz klient steruje serwerem 
wydając polecenie pobrania danych.