Czym one są i jak działają?
Kontekstem jest SQL Server
Odpowiedzi:
Zarówno w systemach Windows, jak i POSIX, nazwane potoki umożliwiają komunikację między procesami między procesami działającymi na tej samej maszynie. Potoki nazwane dają Ci sposób na wysyłanie danych bez utraty wydajności związanej ze stosem sieciowym.
Podobnie jak w przypadku serwera nasłuchującego adresu IP / portu dla żądań przychodzących, serwer może również skonfigurować nazwany potok, który może nasłuchiwać żądań. W obu przypadkach proces klienta (lub biblioteka dostępu do bazy danych) musi znać konkretny adres (lub nazwę potoku), aby wysłać żądanie. Często istnieje powszechnie używana standardowa wartość domyślna (podobnie jak port 80 dla HTTP, serwer SQL używa portu 1433 w protokole TCP / IP; \\. \ Pipe \ sql \ query dla nazwanego potoku).
Konfigurując dodatkowe potoki nazwane, można mieć uruchomionych wiele serwerów DB, każdy z własnymi odbiornikami żądań.
Zaletą potoków nazwanych jest to, że są one zwykle znacznie szybsze i zwalniają zasoby stosu sieciowego.
- BTW, w świecie Windows możesz również mieć nazwane potoki do zdalnych maszyn - ale w takim przypadku nazwany potok jest przesyłany przez TCP / IP, więc stracisz wydajność. Użyj nazwanych potoków do komunikacji z maszyną lokalną.
Unix i Windows mają rzeczy zwane „nazwanymi potokami”, ale zachowują się inaczej. W systemie Unix nazwany potok to jednokierunkowa ulica, która zazwyczaj ma tylko jednego czytelnika i jednego pisarza - piszący pisze, a czytelnik czyta, rozumiesz?
W systemie Windows rzecz zwana „nazwanym potokiem” jest obiektem IPC bardziej podobnym do gniazda TCP - rzeczy mogą płynąć w obie strony i istnieją pewne metadane (można uzyskać dane uwierzytelniające rzeczy na drugim końcu itp.).
Nazwane potoki systemu Unix pojawiają się jako specjalny plik w systemie plików i można uzyskać do niego dostęp za pomocą zwykłych poleceń we / wy plików, w tym powłoki. Windows tego nie robi i trzeba je otworzyć specjalnym wywołaniem systemowym (po czym zachowują się głównie jak normalny uchwyt win32).
Jeszcze bardziej zagmatwane jest to, że Unix ma coś, co nazywa się „gniazdem uniksowym” lub gniazdem AF_UNIX, które działa bardziej jak (ale nie do końca) „nazwany potok” win32, będąc dwukierunkowym.
Mechanizm komunikacji międzyprocesowej w systemie Linux Pipes First In First Out (FIFO).
Nienazwane potoki
W wierszu poleceń, reprezentowane przez „|” między dwoma poleceniami.
Nazwane
potoki Plik specjalny FIFO. Po utworzeniu potoku możesz używać go tak jak zwykłego pliku (otwierać, zamykać, zapisywać, czytać itp.).
Aby utworzyć nazwany potok o nazwie „myPipe” z wiersza poleceń ( strona podręcznika ):
mkfifo myPipe
Aby utworzyć nazwany potok z c, gdzie „pathname” to nazwa, którą chciałbyś, aby potok miał, a „mode” zawiera uprawnienia, które ma mieć potok ( strona podręcznika ):
#include <sys/types.h>
#include <sys/stat.h>
int mkfifo(const char *pathname, mode_t mode);
tell()ustawić ani seek()w rurze.
Według Wikipedii :
[...] Tradycyjny potok jest „nienazwany”, ponieważ istnieje anonimowo i istnieje tylko tak długo, jak trwa proces. Nazwany potok jest trwały w systemie i istnieje poza czasem trwania procesu i musi zostać „odłączony” lub usunięty, gdy nie jest już używany. Procesy zazwyczaj są dołączane do nazwanego potoku (zwykle występującego jako plik) w celu wykonania IPC (komunikacja między procesami).
Porównać
echo "test" | wc
do
mkdnod apipe p
wc apipe
wc będzie blokować do
echo "test" > apipe
wykonuje
Potoki to sposób przesyłania strumieniowego danych między aplikacjami. W Linuksie używam tego cały czas do przesyłania danych wyjściowych jednego procesu do drugiego. Jest to anonimowe, ponieważ aplikacja docelowa nie ma pojęcia, skąd pochodzi ten strumień wejściowy. Nie ma takiej potrzeby.
Nazwany potok jest tylko sposób aktywnie zaczepiając na istniejącej rury i odkurzanie-up swoje dane. Ma to zastosowanie w sytuacjach, w których dostawca nie wie, którzy klienci będą jeść dane.
To jest przykład z Technet (więc nie jestem pewien, dlaczego zaznaczona odpowiedź mówi, że nazwane potoki są szybsze?):
Potoki nazwane a gniazda TCP / IP
W środowisku szybkiej sieci lokalnej (LAN) gniazda protokołu kontroli transmisji / protokołu internetowego (TCP / IP) i klienty potoków nazwanych są porównywalne pod względem wydajności. Jednak różnica w wydajności między klientami gniazd TCP / IP i klientami potoków nazwanych staje się widoczna w przypadku wolniejszych sieci, takich jak sieci rozległe (WAN) lub sieci dial-up. Dzieje się tak z powodu różnych sposobów komunikowania się mechanizmów komunikacji międzyprocesowej (IPC) między urządzeniami równorzędnymi.
W przypadku potoków nazwanych komunikacja sieciowa jest zwykle bardziej interaktywna. Partner nie wysyła danych, dopóki inny peer nie poprosi o to za pomocą polecenia odczytu. Odczyt sieci zazwyczaj obejmuje serię komunikatów wglądu do nazwanych potoków, zanim zacznie odczytywać dane. Może to być bardzo kosztowne w powolnej sieci i powodować nadmierny ruch w sieci , co z kolei wpływa na innych klientów sieci.
Ważne jest również, aby wyjaśnić, czy mówisz o rurach lokalnych czy rurach sieciowych. Jeśli aplikacja serwera działa lokalnie na komputerze, na którym jest uruchomione wystąpienie programu SQL Server, lokalny protokół potoków nazwanych jest opcją. Lokalne nazwane potoki działają w trybie jądra i są bardzo szybkie.
W przypadku gniazd TCP / IP transmisje danych są bardziej usprawnione i mają mniejszy narzut. Transmisje danych mogą również wykorzystywać mechanizmy zwiększające wydajność gniazd TCP / IP, takie jak okienkowanie, opóźnione potwierdzenia i tak dalej. Może to być bardzo pomocne w powolnej sieci. W zależności od rodzaju aplikacji, takie różnice w wydajności mogą być znaczne.
Gniazda TCP / IP obsługują również kolejkę zaległości. Może to zapewnić ograniczony efekt wygładzania w porównaniu z nazwanymi potokami, które mogą prowadzić do błędów zajętości potoku podczas próby połączenia się z SQL Server.
Ogólnie rzecz biorąc, protokół TCP / IP jest preferowany w powolnej sieci LAN, WAN lub sieci dial-up, podczas gdy nazwane potoki mogą być lepszym wyborem, gdy szybkość sieci nie jest problemem, ponieważ oferuje większą funkcjonalność, łatwość użycia i opcje konfiguracji.
Komunikacja między procesami (głównie) dla aplikacji Windows. Podobne do używania gniazd do komunikacji między aplikacjami w systemie Unix.
Nazwane potoki w kontekście unix / linux mogą być użyte do stworzenia dwóch różnych powłok do komunikacji, ponieważ powłoka po prostu nie może nic współużytkować z inną.
Co więcej, jeden skrypt utworzony dwukrotnie w tej samej powłoce nie może nic współużytkować przez te dwie instancje. Znalazłem zastosowanie nazwanych potoków podczas kodowania demona, który zawiera funkcję start () i stop () i chciałem użyć tego samego skryptu do wykonania tych dwóch działań.
Bez nazwanych potoków (lub jakiegokolwiek semafora) uruchamianie skryptu w tle nie stanowi problemu. Chodzi o to, że po zakończeniu nie możesz uzyskać dostępu do instancji w tle.
Więc kiedy chcesz wysłać mu polecenie stop, po prostu nie możesz: uruchomienie tego samego skryptu bez nazwanych potoków i wywołanie funkcji stop () nic nie da, ponieważ w rzeczywistości uruchamiasz inną instancję.
Rozwiązaniem było zaimplementowanie dwóch potoków, jednego READ, a drugiego WRITE podczas uruchamiania demona. Następnie każ mu, między innymi, posłuchać fajki READ. Następnie funkcja Stop () zawiera polecenie, które zapisze wiadomość w potoku, który zostanie obsłużony przez działający w tle skrypt, który wykona wyjście 0. W ten sposób nasza druga instancja tego samego skryptu ma tylko zadanie do wykonania: powiedz pierwszej instancji, aby się zatrzymała.
W ten sposób jeden i tylko jeden skrypt może sam się uruchamiać i zatrzymywać.
Oczywiście możesz to zrobić na różne sposoby, na przykład uruchamiając zatrzymanie za pomocą dotyku. Ale ten jest przyjemny i interesujący do kodowania.
Nazwane potoki to system Windows do komunikacji między procesami. W przypadku serwera SQL, jeśli serwer znajduje się na tym samym komputerze co klient, do przesyłania danych można użyć potoków nazwanych, w przeciwieństwie do protokołu TCP / IP.