named-pipes

问题 I'm attempting to use a named pipe using a .net NamedPipeServerStream asynchronously using callbacks in powershell. I'm currently using the following code: Server side: $myCallback = [AsyncCallback]{ "Connected" } $pipe = New-Object System.IO.Pipes.NamedPipeServerStream("alert", [System.IO.Pipes.PipeDirection]::InOut, 1, [System.IO.Pipes.PipeTransmissionMode]::Message, [System.IO.Pipes.PipeOptions]::Asynchronous) $pipe.BeginWaitForConnection($myCallback, "alertCallback") Client side: $pipe =

问题 I am frustrated. Okay, here is the error. There was no endpoint listening at net.pipe://localhost/MyIpcAppToService that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. I finally got the App.Config file working, at least no complaints. Current App.Config <?xml version="1.0" encoding="utf-8"?> <configuration> <!-- When deploying the service library project, the content of the config file must be added to

问题 I am having trouble locating an example for creating a windows named pipe in matlab. Any suggestions on how to program or where to look? 回答1: Using .NET's System.IO.Pipes is probably the easiest way out of the box, easier than writing a MEX file to call the Win32 API. Matlab lets you call .NET directly from M-code, and the objects are managed so resource cleanup will be easier. .NET 3.5 and newer support named pipes. The resulting M-code would look something like this. (Sorry; I don't have

问题 I am having trouble locating an example for creating a windows named pipe in matlab. Any suggestions on how to program or where to look? 回答1: Using .NET's System.IO.Pipes is probably the easiest way out of the box, easier than writing a MEX file to call the Win32 API. Matlab lets you call .NET directly from M-code, and the objects are managed so resource cleanup will be easier. .NET 3.5 and newer support named pipes. The resulting M-code would look something like this. (Sorry; I don't have

问题 It seems that a successful test of the existence of a windows named pipe by using os.path.exists() prevents the pipe from working. Why would this be? Here is successfully working windows named-pipe code: import time import multiprocessing as mp import win32pipe, win32file PIPENAME = r'\\.\pipe\Foo' def producer(pipe_name: str): print('producer') # if not os.path.exists(pipe_name): # print(f'No pipe {pipe_name}') # return pipe = win32file.CreateFile(pipe_name, win32file.GENERIC_READ |

问题 It seems that a successful test of the existence of a windows named pipe by using os.path.exists() prevents the pipe from working. Why would this be? Here is successfully working windows named-pipe code: import time import multiprocessing as mp import win32pipe, win32file PIPENAME = r'\\.\pipe\Foo' def producer(pipe_name: str): print('producer') # if not os.path.exists(pipe_name): # print(f'No pipe {pipe_name}') # return pipe = win32file.CreateFile(pipe_name, win32file.GENERIC_READ |

问题 i wanted to know if it's possible to restrict remote machines to access named pipe in a server. i'm initializing the server as follows: NamedPipeServerStream pipeServer = new NamedPipeServerStream("myPipe", PipeDirection.InOut, NamedPipeServerStream.MaxAllowedServerInstances, PipeTransmissionMode.Byte, PipeOptions.Asynchronous); the remote client does: using (NamedPipeClientStream pipeStream = new NamedPipeClientStream(serverIP, "myPipe", PipeDirection.InOut)) { pipeStream.Connect(2000); }

问题 I write this program to test the FIFO in Ubuntu。The main program create a child process to write something ,and then the parent read and print it /* communication with named pipe(or FIFO) @author myqiqiang @email myqiqiang@gmail.com */ #include<sys/types.h> #include<sys/stat.h> #include<stdio.h> #include<errno.h> #include<fcntl.h> #include<string.h> #define FIFO_SERVER "/home/myqiqiang/fifoserver" //fifo directioy #define BUFFERSIZE 80 void main() { pid_t pc; int flag,fd; char data[BUFFERSIZE

问题 I am using POSIX named pipes (fifos) to send records from one or more threads to be read by another thread (only one thread does the reading). However, the 83rd record out of 100 records is simply dropped. The client core calls write and the return value is correctly reported as the length of the record (720 bytes) so the client (writer) core confirms that the record is sent, but switching to the reader core in gdb debug mode with scheduler-locking on, I cycle through reading the few previous

问题 Code snippet: void RunThread(void* unused_args) { PSECURITY_DESCRIPTOR sdsc; ULONG size; ConvertStringSecurityDescriptorToSecurityDescriptor("S:(ML;;NW;;;LW)", SDDL_REVISION_1, &sdsc, &size); SECURITY_ATTRIBUTES sa; sa.nLength = sizeof(sa); sa.bInheritHandle = false; sa.lpSecurityDescriptor = sdsc; HANDLE pipe = CreateNamedPipe("\\.\pipe\mmaivpc_test_pipe", PIPE_ACCESS_DUPLEX, PIPE_TYPE_BYTE, 255, 1024, 1024, 0, &sa); DWORD error = GetLastError(); } If you haven't figured it out from the