Simultanément en lecture/écriture de canal nommé en Java (sur windows)

Ce comportement est normal de tuyaux. Il est censé accrocher jusqu'à d'autres processus se connecte à la pipe et au lit.

OriginalL'auteur Eagle

J'ai le même problème -- la communication entre un C#/Python application et une application Java sur windows à l'aide de canaux nommés:

Nous avons l'exemple de Code Client écrit en Java, mais en ligne String echoResponse = pipe.readLine(); de la bande de roulement attend toujours.

try {
    //Connect to the pipe
    RandomAccessFile pipe = new RandomAccessFile("\\\\.\\pipe\\testpipe", "rw");
    String echoText = "Hello word\n";
    //write to pipe
    pipe.write ( echoText.getBytes() );
    //read response
    String echoResponse = pipe.readLine();
    System.out.println("Response: " + echoResponse );
    pipe.close();

    } catch (Exception e) {
    //TODO Auto-generated catch block
    e.printStackTrace();
    }

Solution du problème:
J'ai un ServerPipe code écrit sur le langage Python à partir d'ici Exemple Le Nom De Code De Tuyaux:
et d'exécuter ses sur Python 2.6.6

from ctypes import *
PIPE_ACCESS_DUPLEX = 0x3
PIPE_TYPE_MESSAGE = 0x4
PIPE_READMODE_MESSAGE = 0x2
PIPE_WAIT = 0
PIPE_UNLIMITED_INSTANCES = 255
BUFSIZE = 4096
NMPWAIT_USE_DEFAULT_WAIT = 0
INVALID_HANDLE_VALUE = -1
ERROR_PIPE_CONNECTED = 535
MESSAGE = "Default answer from server\0"
szPipename = "\\\\.\\pipe\\mynamedpipe"
def ReadWrite_ClientPipe_Thread(hPipe):
chBuf = create_string_buffer(BUFSIZE)
cbRead = c_ulong(0)
while 1:
fSuccess = windll.kernel32.ReadFile(hPipe, chBuf, BUFSIZE,
byref(cbRead), None)
if ((fSuccess ==1) or (cbRead.value != 0)):
print chBuf.value
cbWritten = c_ulong(0)
fSuccess = windll.kernel32.WriteFile(hPipe,
c_char_p(MESSAGE),
len(MESSAGE),
byref(cbWritten),
None
)
else:
break
if ( (not fSuccess) or (len(MESSAGE) != cbWritten.value)):
print "Could not reply to the client's request from the
pipe"
break
else:
print "Number of bytes written:", cbWritten.value
windll.kernel32.FlushFileBuffers(hPipe)
windll.kernel32.DisconnectNamedPipe(hPipe)
windll.kernel32.CloseHandle(hPipe)
return 0
def main():
THREADFUNC = CFUNCTYPE(c_int, c_int)
thread_func = THREADFUNC(ReadWrite_ClientPipe_Thread)
while 1:
hPipe = windll.kernel32.CreateNamedPipeA(szPipename,
PIPE_ACCESS_DUPLEX,
PIPE_TYPE_MESSAGE |
PIPE_READMODE_MESSAGE
|
PIPE_WAIT,
PIPE_UNLIMITED_INSTANCES,
BUFSIZE, BUFSIZE,
NMPWAIT_USE_DEFAULT_WAIT,
None
)
if (hPipe == INVALID_HANDLE_VALUE):
print "Error in creating Named Pipe"
return 0
fConnected = windll.kernel32.ConnectNamedPipe(hPipe, None)
if ((fConnected == 0) and (windll.kernel32.GetLastError() ==
ERROR_PIPE_CONNECTED)):
fConnected = 1
if (fConnected == 1):
dwThreadId = c_ulong(0)
hThread = windll.kernel32.CreateThread(None, 0,
thread_func, hPipe, 0, byref(dwThreadId))
if (hThread == -1):
print "Create Thread failed"
return 0
else:
windll.kernel32.CloseHandle(hThread)
else:
print "Could not connect to the Named Pipe"
windll.kernel32.CloseHandle(hPipe)
return 0
if __name__ == "__main__":
main()

Serveur après avoir démarrer, vous pouvez utiliser la version légèrement modifiée de la Client Java code:

try {
//Connect to the pipe
RandomAccessFile pipe = new RandomAccessFile("\\\\.\\pipe\\mynamedpipe", "rw");
String echoText = "Hello world\n";
//write to pipe
pipe.write(echoText.getBytes());
//String aChar;
StringBuffer fullString = new StringBuffer();
while(true){
int charCode = pipe.read();
if(charCode == 0) break;
//aChar = new Character((char)charCode).toString();
fullString.append((char)charCode);
}
System.out.println("Response: " + fullString);
pipe.close();
}
catch (Exception e) {
//TODO Auto-generated catch block
e.printStackTrace();
}

Il fonctionne bien dans NetBeans 6.9.1.

OriginalL'auteur Andrey

Je ne suis pas familier avec JAVA, et mon C# est assez élémentaire. Cependant, j'ai eu un problème similaire avec un multithread C++ client que j'ai corrigé par l'ouverture du canal pour se chevauchaient IO. Jusqu'à ce que j'ai fait cela, Windows sérialisé lit et écrit, efficacement, causant un insatisfait (blocage) ReadFile pour empêcher l'achèvement d'une WriteFile jusqu'à ce que la lecture a été faite.

Voir La fonction CreateFile

FILE_FLAG_OVERLAPPED

OriginalL'auteur StanBell