I am trying to send some data via Named Pipes. I created Named Pipe Server in C# and client in MQL5 (it is just a C++ wrapper). Server works fine and can be reached from Named Pipe Client written in C# so communication C# <-> C# works fine. Also i tried utility PipeList and it also shows that my pipe server is visible and available.
The only problem is with client written in MQL5 (C++) - it does not find the path to the pipe server so communication MQL <-> C# is failing.
Could anybody suggest :
what am i doing wrong?
how to check that both C# and MQL are accessing the same physical
path and the same location?
Server :
NamedPipeServerStream pipeStream = new NamedPipeServerStream("MQL5", PipeDirection.In, 1, PipeTransmissionMode.Byte)
I also tried full path \\\\.\\pipe\\MQL5 with no success
Client :
CFilePipe iPipe;
while(IsStopped() == false)
{
Print("This loop is infinite because there is no connection");
if (iPipe.Open("\\\\.\\pipe\\MQL5", FILE_READ | FILE_WRITE | FILE_BIN) != INVALID_HANDLE) break;
Sleep(250);
}
Thanks.
Answer is found. Seems that was simply my own mistake or this is how Pipes work in MQL - channel always needs to be Duplex so line in C# needs to be replaced with the following :
NamedPipeServerStream pipeStream = new NamedPipeServerStream(name, PipeDirection.InOut, 1, PipeTransmissionMode.Byte)
Parameter PipeDirection.InOut says pipe to be two-way.
P.S. Though it is a little weird anyway because conjunction C# Server <-> C# Client can work in both modes (In / Out or one of them)
Server: C# / Client: MetaTrader
I had two other problems:
The client and server needed to be run as Administrator
I needed to set buffer size for input and ouput (Default is zero =>
dynamically calculated => there was an error on this).
Related
I have a C# .net server service application which listens on port 11111 for a connection. I have tested it with another c# test application which can send and recieve communication for and from the server.
Now the production scenario is that this C# .net server application is to recieve connection from, amongst others, a nodejs client which is encapsulated in Electron. So i create this function in NodeJS
const net = require( "net");
const socket = new net.Socket();
socket.connect('11111','127.0.0.1');
exports.socket = socket;
I import it in the IPC layer of Electron.
const { socket } = require("./socketInit.js");
and when doing that i get this error
A JavaScript error occurred in the browser process
Error: connect ECONNREFUSED 127.0.0.1:11111
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16)
It wont connect to the server socket.
Im not even using the socket yet, but i understand that the connection attempt is doing the handshake and that must be where the error happens.
Does anyone have any idea what could be wrong ?
TY for your time!
Im quite sure it is because the code is in a renderpass which runs several times, and then the code in reality tries to open a connection on a port where a connection is already open each time there is a renderpass except from the first.
I destroyed the connection after sending and now i dont get the error anymore. But im not getting any data send to the server, but that is for another question.
I'm integrating this into an existing codebase, which i don't fully understand as im a total newb to NodeJS, Javascript and Electron, so im not sure how it all works :)
I'm using a DuplexChannelFactory to create a named pipe on net.pipe://localhost/test. However, when I run my program, I get an error: Cannot listen on pipe name "net.pipe://localhost/" because another pipe endpoint is already listening on that name.
So I tried to see whether this was actually the case, by opening a powershell and typing in [System.IO.Directory]::GetFiles("\\.\\pipe\\), but there is no mention of localhost.
I then also tried to change the address net.pipe://localhost/test to net.pipe://anything/test but it still didn't work.
Finally I restarted the computer and it worked. But restarting the computer is not optimal, and I restarted it again earlier today and it broke again.
Could there be any other reason why I would get this error?
WCF Named pipes operate on a different system to regular nameed pipes. When you open a regular named pipe on localhost, you will get a pipe at \.\pipe\localhost, but when you open a WCF pipe you will get \.\pipe\some-guid-xxxx-xxxx. This generated GUID is consistent for WCF named pipes of the same name, which is why it works seamlessly. (see Prevent Named Pipes Conflict)
Now, in my code, I wanted to create a named pipe on localhost. It didn't show up in [System.IO.Directory]::GetFiles("\\.\\pipe\\), because WCF uses a UUID.
The workaround I used in the end is to specify the pipe url as net.pipe\localhost\something_specific_to_me and have an additional AddServiceEndpoint(...,"something_else"), so that the final pipe could be connected to via net.pipe\localhost\something_specific_to_me\something_else.
I am able to have c# (client) and python (server) talk to each other by using a simple request-reply. However, I want my web application built on c# asp.net to be stable and need more clients and servers, so I tried connecting c# and python using the Router-Dealer Proxy with python.
I tried running the proxy python script first, then running c# (client), then python (server). However, when I run the python (server), it gives me an "Address in use" error message.
Am I running them in a wrong order OR is there something wrong with the proxy python script (shown below)?
5602 = c# client
5603 = python server
def main():
context = zmq.Context()
# Socket facing clients
frontend = context.socket(zmq.ROUTER)
frontend.bind("tcp://*:5602")
# Socket facing services
backend = context.socket(zmq.DEALER)
backend.bind("tcp://*:5603")
zmq.proxy(frontend, backend)
# We never get here…
frontend.close()
backend.close()
context.term()
if __name__ == "__main__":
main()
I'm assuming your servers use bind, so the proxy should connect to them rather than also using bind.
Note: in zeromq the order of application startup doesn't matter so you can tell your proxy to connect to a server that doesn't yet exist, when the server is started the connection will be made.
I am trying to port my server code from Linux to Windows, so I thought that easiest way would be to write a wrapper in C#.
Basically, what I would C# would do is:
C# loads Server.dll written entirely in C++ containing functions:
InsertClient(sockId)
DisconnectClient(sockId)
ProcessResponse(sockId,len,buffer)
C# creates basic server bound to port N on TCP.
When C# server accepts new client and gets Socket struct as return, it must call DLL function InsertClient(sockId)
When C# server receives some data from the client, it sends it again to DLL function ProcessResponse(sockId,len,data)
While data are processed all the time in Server.dll and some event happens, Server.dll would send response back to client using the only available function in C++ for sending data: send(sockId,buffer,len,flags)
But here it comes to the problem, at point 5, I need to already use socket ID, because without it I can't use send(...) , so what I could do is:
Server.dll would invoke call back to main C# application to some somehow exported function, like SendPacket containing pointer to Socket struct, which I absolutely don't know if it's possible without using thousands of other framework go arounds.
In C# I would somehow get to the Socket ID from Socket struct, and send it to C++, so C++ can use it for simple send(...)
I am trying to get data from my interface, written in c, to another application, in c#.
Now, I'm not sure if WinSocks is pure c, but I'm using visual studio and the rest of my interface is 100% pure C.
Here is my "client" written in c#
http://pastebin.com/X9SNcVqn
here is my "server" written in c - loops waiting for a connection, this builds AND RUNS without issues
NOTE: DEFAULT_PORT is 18042, used the same port for client and server side.
I've downloaded wireshark and used the command "tcp.port eq "
http://pastebin.com/FHZyre2V
I also tried going through my windows firewall and NORTON to allow this connection, I couldn't figure out what to do. Most of the tuts I saw where outdated and tabs and options are changed in WINDOWS 7
I chose a port that wasn't being used, I tried using wireshark to see the connections, no luck BUT I scanned the port I used with nmap, before AND after I ran the "server", so it must of atleast have been created
In your C# code you are mixing TcpClient and Socket objects. You don't need both, only the TcpClient. (The Socket code is using the wrong port as well). Once the TcpClient object is connected, call the GetStream method to get a NetworkStream object that you can read and write to to send and receive data to the server process.
See the example code in the documentation, here: http://msdn.microsoft.com/en-us/library/system.net.sockets.tcpclient.aspx
Your client code contains:
IPEndPoint endPoint = new IPEndPoint(IPAddress.Parse("192.168.1.4"), 18041);
I would not necessarily expect the IP address bound to a network card to necessarily work for localhost-to-localhost connections. I'd recommend changing your client to use 127.0.0.1 or another suitable loopback address.
First,check if the IP adress is correct and if the corresponding port is listeing.
netstat -an | find "port number"
and I think, in the server side code
local.sin_port = (unsigned short)DEFAULT_PORT;
Should be:
local.sin_port = htons((unsigned short)DEFAULT_PORT);