Nazwane operacje potoku

Po raz pierwszy serwer potoku wywołuje funkcję CreateNamedPipe, używa nMaxInstances parametru, aby określić maksymalną liczbę wystąpień potoku, które mogą istnieć jednocześnie. Serwer może wywoływać CreateNamedPipe wielokrotnie w celu utworzenia dodatkowych wystąpień potoku, o ile nie przekracza maksymalnej liczby wystąpień. Jeśli funkcja powiedzie się, każde wywołanie zwraca uchwyt na końcu serwera nazwanego wystąpienia potoku.

Gdy tylko serwer potoku utworzy wystąpienie potoku, klient potoku może nawiązać z nim połączenie, wywołując CreateFile lub CallNamedPipe funkcji. Jeśli wystąpienie potoku jest dostępne, CreateFile zwraca uchwyt na końcu klienta wystąpienia potoku. Jeśli nie są dostępne żadne wystąpienia potoku, klient potoku może użyć funkcji WaitNamedPipe czekać, aż potok stanie się dostępny.

Serwer potoku może określić, kiedy klient potoku jest połączony z wystąpieniem potoku, wywołując funkcję ConnectNamedPipe. Jeśli dojście potoku jest w trybie oczekiwania blokującego, ConnectNamedPipe nie zwraca się, dopóki klient nie zostanie połączony.

Klienci potoków i serwery mogą wywoływać jedną z kilku funkcji — oprócz CallNamedPipe — odczytywać i zapisywać w nazwanym potoku. Zachowanie tych funkcji zależy od typu potoku i trybów efektu dla określonego uchwytu potoku w następujący sposób:

• Funkcje ReadFile i WriteFile mogą być używane z potokami typu bajtowego lub typu komunikatu.
• Funkcje ReadFileEx i WriteFileEx mogą być używane z potokami typu bajtowego lub typu komunikatu, jeśli dojście potoku zostało otwarte dla nakładających się operacji.
• Funkcja PeekNamedPipe może służyć do odczytywania bez usuwania zawartości potoku typu bajtowego lub potoku typu komunikatu. PeekNamedPipe może również zwrócić dodatkowe informacje o wystąpieniu potoku.
• Funkcja TransactNamedPipe może być używana z potokami dwukierunkowymi typu komunikatów, jeśli dojście potoku do procesu wywołującego jest ustawione na tryb odczytu komunikatów. Funkcja zapisuje komunikat żądania i odczytuje komunikat odpowiedzi w jednej operacji, zwiększając wydajność sieci.

Serwer potoku nie powinien wykonywać blokującej operacji odczytu do momentu uruchomienia klienta potoku. W przeciwnym razie może wystąpić stan wyścigu. Zwykle występuje to, gdy kod inicjowania, taki jak biblioteka czasu wykonywania języka C, musi zablokować i zbadać dziedziczone dojścia.

Po zakończeniu działania klienta i serwera przy użyciu wystąpienia potoku serwer powinien najpierw wywołać funkcję FlushFileBuffers, aby upewnić się, że wszystkie bajty lub komunikaty zapisane w potoku są odczytywane przez klienta. FlushFileBuffers nie zwraca się, dopóki klient nie odczytuje wszystkich danych z potoku. Następnie serwer wywołuje funkcję DisconnectNamedPipe, aby zamknąć połączenie z klientem potoku. Ta funkcja sprawia, że uchwyt klienta jest nieprawidłowy, jeśli nie został jeszcze zamknięty. Wszystkie nieprzeczytane dane w potoku zostaną odrzucone. Po rozłączeniu klienta serwer wywołuje funkcję CloseHandle, aby zamknąć dojście do wystąpienia potoku. Alternatywnie serwer może użyć ConnectNamedPipe, aby umożliwić nowemu klientowi nawiązanie połączenia z tym wystąpieniem potoku.

Proces może pobrać informacje o nazwanym potoku, wywołując funkcję GetNamedPipeInfo, która zwraca typ potoku, rozmiar wejściowych i wyjściowych oraz maksymalną liczbę wystąpień potoku, które można utworzyć. Funkcja GetNamedPipeHandleState raportuje tryby odczytu i oczekiwania uchwytu potoku, bieżącą liczbę wystąpień potoku i dodatkowe informacje dotyczące potoków komunikujących się za pośrednictwem sieci. Funkcja SetNamedPipeHandleState ustawia tryb odczytu i oczekiwania uchwytu potoku. W przypadku klientów potoku komunikujących się z serwerem zdalnym funkcja kontroluje również maksymalną liczbę bajtów do zebrania lub maksymalny czas oczekiwania przed przesłaniem komunikatu (przy założeniu, że dojście klienta nie zostało otwarte z włączonym trybem zapisu).