Problem z Windows Named Pipe: Kod błędu 233 na przemian

Question

Potrzebuję pomocy w sprawie mojego wniosku, który robię. Jest to prosty program, który reaguje na parametry wiersza poleceń. Jeśli aplikacja zostanie wywołana po raz pierwszy, uruchamia się jako serwer potoku (blokowanie, nie nakładanie się) w innym wątku poświęconym temu wątkowi, podczas gdy główny wątek robi coś innego. Teraz użytkownik może nadal wywoływać aplikację przy użyciu tych samych parametrów wykonywalnych aplikacji i wiersza poleceń, ale ponieważ nie jest to pierwsza instancja aplikacji, przekazuje parametry wiersza polecenia do pierwszej instancji za pomocą potoku, a następnie zabija sam. Tak, to jest jak proces singleton w deseniu-żargonie.

Idealnie powinno być tak:

app.exe "first" // starts app.exe as a pipe server and prints "first" 
app.exe "second" // client process causes server instance to print "second" 
app.exe "third" // client process causes server instance to print "third" 
app.exe "fourth" // client process causes server instance to print "fourth" 
app.exe "fifth" // client process causes server instance to print "fifth" 
app.exe -quit  // client process causes server instance to terminate. 

Teraz moim jedynym problemem jest to, kiedy robię powyższych linii tak się dzieje:

app.exe "first" // starts app.exe as a pipe server and prints "first" 
app.exe "second" // client process returns a GetLastError code of 233 
app.exe "third" // client process causes server instance to print "third" 
app.exe "fourth" // client process returns a GetLastError code of 233 
app.exe "fifth" // client process causes server instance to print "fifth" 
app.exe -quit  // client process returns a GetLastError code of 233 

Moje kod serwera rura coś takiego (pseudo kod):

CreateNamedPipe(); 
// Code below now runs on a separate thread... 
while(!Quit) 
{ 
    if(ConnectNamedPipe() is successful) 
    { 
     if(PeekNamedPipe() has a message) 
     { 
      ReadFile(); 
      ProcessReceivedMessage(); 
     } 
     FileFlushBuffers(); 
     DisconnectNamedPipe(); 
    } 
} 
CloseHandle(the pipe); 

Moja wersja klient idzie tak (pseudo kod):

if(WaitNamedPipe(FOREVER) != 0) 
{ 
    GetParametersAndFormAMessage(); 
    CreateFile(); 
    WriteFile(); // Sends message to the pipe server 
} 
CloseHandle(); 

Według MSDN, jeśli serwer używa DisconnectNamedPipe(), klient jest zmuszony do rozłączenia i przy następnej próbie klienta, otrzyma błąd. Czy uważasz, że to jest powód? Jeśli tak, jak mogę odłączyć klienta bez wystąpienia tego dodatkowego błędu? W przeciwnym razie, cokolwiek powinienem wiedzieć, aby to wykonać? Spędziłem wiele godzin, zastanawiając się nad tym.

Answer 1

Powinieneś obsługiwać komunikację z każdą instancją klienta na innej instancji serwera po stronie rury, używając oddzielnego wątku dla każdego. Tak więc, gdy zwraca się ConnectNamedPipe(), natychmiast odradza się nowy wątek odsłuchiwacza, aby czekać na następnego klienta, przed przetworzeniem wiadomości od klienta, który właśnie się połączył.

Każdy klient będzie rozmawiał przez świeżo utworzoną instancję potoku, a nie zobaczysz błędów ERROR_PIPE_NOT_CONNECTED.

tj psuedo-kod coś takiego:

Main Thread 
{ 
    CreateListenerThread(); 
    WaitForQuitEvent(); 
} 

ListenerThread 
{ 
    ConnectNamedPipe(); 
    if (no error) 
    { 
     CreateListenerThread(); 
     if(PeekNamedPipe() has a message) 
     { 
      ReadFile(); 
      ProcessReceivedMessage(); // if -quit signal quit event 
     } 
     FileFlushBuffers(); 
     DisconnectNamedPipe(); 
     CloseHandle(); 
    } 
    else 
    { 
     // handle/report error 
    } 
}