2010-12-15 10 views
7

Ich brauche Hilfe für meine Anwendung, die ich mache. Es ist ein einfaches Programm, das auf Kommandozeilenparameter reagiert. Wenn die Anwendung zum ersten Mal aufgerufen wird, startet sie als Pipe-Server (blockierend, nicht überlappend) in einem anderen Thread, der ihr gewidmet ist, während der Haupt-Thread etwas anderes tut. Jetzt kann der Benutzer die Anwendung immer noch mit den gleichen ausführbaren Programmparametern und Befehlszeilenparametern aufrufen, da er jedoch nicht die erste Instanz der Anwendung ist, übergibt er die Befehlszeilenparameter mithilfe der Pipe an die erste Instanz und beendet dann selbst. Es ist also wie ein Singleton-Prozess in Patterns-Lingo.Windows Named Pipe Problem: Fehlercode 233 wechselt

Idealerweise sollte es so sein:

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. 

Nun, mein Problem ist nur, wenn ich die obigen Zeilen tun dies geschieht:

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 

Mein Pipe-Server-Code geht etwas ähnliches (Pseudocode):

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); 

Meine Client-Version wie das geht (Pseudocode):

Nach MSDN, wenn der Server DisconnectNamedPipe() verwendet, wird der Client zwangsweise getrennt und beim nächsten Versuch des Clients erhalten sie einen Fehler. Denkst du, dass das der Grund ist? Wenn ja, wie kann ich einen Client trennen, ohne dass ein zusätzlicher Fehler auftritt? Ansonsten, alles was ich wissen sollte, um das zu machen ??? Habe viele Stunden damit verbracht, das herauszufinden.

Antwort

10

Sie sollten die Kommunikation mit jeder Clientinstanz auf einer anderen serverseitigen Instanz der Pipe behandeln, wobei Sie jeweils einen separaten Thread verwenden. Wenn also ConnectNamedPipe() zurückkehrt, spawnen Sie sofort einen neuen Listener-Thread, um auf den nächsten Client zu warten, bevor Sie die Nachricht vom gerade verbundenen Client verarbeiten.

Jeder Client spricht dann über eine neu erstellte Instanz der Pipe, und Sie werden die ERROR_PIPE_NOT_CONNECTED Fehler nicht sehen.

dh psuedo-Code etwa wie folgt:

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 
    } 
} 
+0

Dies würde logisch bedeuten, dass Sie einen Thread haben, die nicht angeschlossen sind, erhalten (weil jeder Thread, der angeschlossen ist, bekommen startet einen neuen Thread) und nur bleibt sitzen und wartet darauf, dass sich ein Client mit ihm verbindet. Wie stellen Sie sicher, dass dieser Thread nach Abschluss der Ausführung ordnungsgemäß bereinigt wird? –

Verwandte Themen