Czy PHP może asynchronicznie korzystać z gniazd?

Question

Typowa funkcjonalność gniazda PHP jest synchroniczna i zatrzymuje wątek podczas oczekiwania na połączenia przychodzące i dane. (np. socket_read i socket_listen)

Jak zrobić to samo asynchronicznie? więc mogę odpowiadać na dane w zdarzeniu odbieranym w danych, zamiast odpytywania danych itp.

Answer 1

Tak, to jest to, do czego służy socket_set_nonblock(). Twój kod interakcji z gniazdem musi być napisany inaczej, biorąc pod uwagę specjalne znaczenia kodów błędów 11, EWOULDBLOCK i 115, EINPROGRESS, załóżmy.

Oto niektóre nieco-fabularyzowany przykładowy kod z pętli gniazdo odpytywania PHP synchronizacji, na wniosek:

$buf = ''; 
$done = false; 
do { 
    $chunk = socket_read($sock, 4096); 
    if($chunk === false) { 
     $error = socket_last_error($sock); 
     if($error != 11 && $error != 115) { 
      my_error_handler(socket_strerror($error), $error); 
      $done = true; 
     } 
     break; 
    } elseif($chunk == '') { 
     $done = true; 
     break; 
    } else { 
     $buf .= $chunk; 
    } 
} while(true); 

Answer 2

AFAIK PHP jest ściśle singlethreaded, co oznacza, że ​​nie może tego zrobić asynchronicznie, ponieważ wykonanie skryptu jest zawsze liniowy.

Minęło trochę czasu, odkąd to zrobiłem, ale o ile sobie przypominam, można otworzyć tylko gniazdo, a skrypt powinien kontynuować wykonywanie po otrzymaniu danych.

Answer 3

Jak zrobić to samo asynchronicznie? więc mogę odpowiedzieć na dane w przypadku danych otrzymał zamiast odpytywania dla danych itp

Trzeba będzie wykonać skrypt i wydawać stream_select sprawdzić weither nie ma żadnych danych do odbioru. Przetwórz i wyślij dane z powrotem.

Answer 4

Termin "asynchroniczny" jest często nadużywany w programowaniu sieciowym. W przypadku operacji we/wy asynchroniczne często są po prostu używane jako inne słowo nie blokujące. Oznacza to, że proces może być kontynuowany przed zakończeniem transmisji w api sieci.

Dla realizacji procesu w ogół asynchroniczny oznacza wielokrotne instrukcje mogą być obliczane jednocześnie (równolegle).

Innymi słowy, asynchroniczny I/O nie jest prawdziwie asynchroniczne o ile kilka nici są stosowane w celu umożliwienia wielokrotnego czyta/zapisuje/akceptuje, aby wystąpiły jednocześnie - wszystkie gniazda będą musiały czekać na synchroniczne wywołanie nieblokujące, jeśli ma dane do odczytu/zapisu lub nie będzie blokować, a odczyt/zapis dużego pliku może nadal zająć sekundy lub nawet minuty, jeśli nie zostanie przerwany. Należy zauważyć, że wymagałoby to doskonałego przepływu między klientem a serwerem lub sam TCP przerwie transmisję. Na przykład serwer wysyłający szybciej niż klient może pobrać, spowoduje blokowanie zapisu.

Z ścisłego punktu widzenia PHP nie może wykonywać asynchronicznych połączeń sieciowych, a jedynie blokować. W skrócie, postęp procesu zatrzyma się, gdy połączenie sieciowe będzie w stanie z pożytkiem odczytywać/zapisywać itd. Jednak proces będzie kontynuowany, gdy wywołanie nie będzie w stanie z pożytkiem odczytać/zapisać lub w przeciwnym razie zablokować. W prawdziwie asynchronicznym systemie proces będzie kontynuowany niezależnie, a odczyt/zapis zostanie wykonany w innym wątku. Zauważ, że blokowanie operacji we/wy może być wykonane asynchronicznie, jeśli zostanie wykonane w innym wątku.

Co więcej, PHP nie jest w stanie wykonywać sterowanych przez zdarzenia operacji we/wy bez instalowania rozszerzenia, które je obsługuje. W przeciwnym razie musisz wykonać jakąś formę odpytywania, aby wykonać nieblokujące operacje we/wy w PHP. Kod z Chaos byłby funkcjonalnym nieblokującym odczytanym przykładem, gdyby używał socket_select.

Przy tym powiedziane, funkcja select nadal zezwala na zachowanie nie blokujące w PHP. W języku C usługi odpytywania mają utratę wydajności w stosunku do zdarzeń, więc jestem pewien, że byłoby to takie samo w przypadku PHP. Ale ta strata jest w nanosekundach-mikrosekundach w zależności od ilości gniazd, gdzie czas zaoszczędzony od połączenia nie blokującego to zwykle milisekundy, a nawet sekundy, jeśli połączenie ma czekać.