Is there a way to implement RDMA RC functionality without invoking the Connection Manager, and therefore skipping the rdma_create_event_channel() ?
Perhaps with a simple exchange of the necessary information through an external protocol, say UDP packets ? And then initialize the QPs with the received parameters.
Has anybody implemented any such off protocol functionality ?
The IB perftest package supports both the traditional Connection Manager method and the bypass version through TCP sockets. See https://github.com/linux-rdma/perftest/blob/8332816c1c2b1911f18ba7230b7784cdb90961e3/src/perftest_communication.h#L165 and its callers.
Related
I am developing an application which will open TCP/IP sockets to remote locations. For each of these connections, messages will flow in both directions asynchronously. There isn't any request-response behavior.
I've been looking at NetMQ and I like the way it manages the connecting and listening of sockets as well as the way it does the frames. But I don't see how it can work with a remote endpoint that doesn't run NetMQ.
Would defining my own socket type work? e.g.
public class MyNetMQSocket: NetMQSocket
There is a long connected TCP socket. Up to two clients can connect to a server. In other words, the load is not high. However, once a TCP connection is made, the socket will not be disconnected unless there is an accident, such as a server power down or network failure. Is it possible to reuse an existing TCP socket when restarting the process? I think TCP load balancer like AWS NLB cannot be used since the existing socket won't be moved to a new application. I'd like to have a deployment without downtime, as the system i'm working on is a system that can suffer financial damage when a socket is broken and data is lost. Low-level socket programming is ok.
I have read CloudFlare's https://blog.cloudflare.com/graceful-upgrades-in-go/ article explaining Nginx's Gracefully Reload mechanism. Since an HTTP server is a server that opens and closes sockets frequently, that article assumes that the server's connection would someday be closed, but my situation is slightly different. So I'm not sure if this can be used.
A socket can be shared between multiple processes, for example by opening the socket in same parent processing and forking a child process. But if the last process using the socket is closed the socket and thus the underlying connection is implicitly closed.
This means you must make sure that there is always a process open which uses the socket. This can be for example done if the deployment of the new software does not first exit the old process and then creates the new one but if the new process would start and the old process would transfer the socket to the new one, see Can I share a file descriptor to another process on linux or are they local to the process?
for how this can be done in Linux. Other ways would be using file descriptor inheritance when doing a fork().
Note that these sharing of file descriptors will only work with plain sockets where the state is fully kept in the OS kernel. It will be much harder or impossible with TLS sockets since in this case also the current user space state somehow needs to be shared.
Another way is to have some intermediate "proxy" which on the hand has the stable socket connection to your fragil application and on the other hand is a robust socket handling (i.e. reconnect when needed) to the application you want to update. Then this proxy transfers the traffic between both sides and will reconnect the socket if needed whenever a problem occurs.
I have to edit an existing VB6 application that deals with Socket requests from client endpoints. What are tools (Classes/methods) that allow one to make an SSL Socket instead of a classic socket. I found out that there is a control called WinSock, but I don't know whether it is suitable for the server's tasks or not.
Any kind of help will be appreciated.
Thanks.
Is it possible to use gRPC such that all calls between two remote hosts
use a TCP connection that is established outside of gRPC? I would also like
to determine whether this TCP connection can be multiplexed for more than
one gRPC call, that the calls may be in either directions, and that gRPC
not close the socket.
The intent is to be able to use gRPC when two ends of gRPC are across a
firewall. The firewall only allows establishing a single TCP connection
that is initiated from within the firewall.
For the requirements only C++ and Java implementations may be on either side.
Maybe. The main problem will probably be that you don't want gRPC to close the socket; it's unclear when you want gRPC to release the socket back to you. It's also unclear whether you need this on server-side or client-side.
gRPC uses HTTP/2 which can naturally multiplex multiple bi-directional calls over a single TCP connection. C++ also allows you to provide it an existing fd. Java doesn't support passing an fd out-of-the-box, but it should be possible using the JNI Netty EpollSocketChannel. I would only expect those to work on client-side today, though.
This may be something that deserves a GitHub issue as a feature request.
Does someone know about a CPAN module on Win32 that captures network packets and edit them on the fly? As far as I know, the only Perl module on Win32 that deals with packets on the fly is Net::Pcap but it only support passive monitoring and not affet the TCP/IP stack.
Is there a such module could someone provide example /reference /documentation ?
As far as I know, libpcap allows you to read copies of incoming and outgoing packets, and some implementations allow you to inject a raw packet, but not rewrite a packet. You would basically have to drop the original packet (something libpcap cannot do) and then inject a new one in it's place.
Firewall apps that allow you to filter incoming and outgoing packets might be able to do something like this. However, since you're talking about Perl and Win32 your options are probably limited.
I think right answer is "implement proxy for this".
If it works in your scenario, try to implement proxy server. Listen on same port as your target service does and read all incoming traffic. If you need modification of packet, do it and pass all traffic to target service. Of course you have to implement both directions.
You can search for basic TCP deamon snippet in perl or maybe you can implement just module for existing proxy server for your service. Is it HTTP or what kind of traffic you need to handle?
I would suggest using Net::Pcap to capture traffic, then the Cygwin port of TCPReplay to modify and replay the traffic. Obviously a Linux setup would be more reliable since TCPreplay would work on it out of the box without requiring cygwin.