Alternative ways to connect to an embedded etcd server - etcd

I use the embedded etcd server for testing and was wondering if there was a more direct in memory way of connecting to it? An alternative to using a socket. The socket isn't a big deal but it feels silly leaving the process only to connect back into the same process via socket, it would be interesting to do that with channels or something.

Related

ZeroMQ connect to physically non connected socket

I'm trying to understand if ZeroMQ can connect pub or sub socket to non existing (yet) ip address. Will it automatically connect when this IP address will appear in the future?
Or should I check up existance first before connecting?
Is the behavior same for PUB and SUB sockets?
The answer is buried somewhat in the manual, here:
for most transports and socket types the connection is not performed immediately but as needed by ØMQ. Thus a successful call to zmq_connect() does not mean that the connection was or could actually be established. Because of this, for most transports and socket types the order in which a server socket is bound and a client socket is connected to it does not matter. The ZMQ_PAIR sockets are an exception, as they do not automatically reconnect to endpoints.
As that quote says, the order of binding and connecting does not matter. This is extremely useful, as you don't then have to worry about start-up order; the client will be quite happy waiting for a server to come online, able to run other things without blocking on the connect.
Other Things That Are Useful
The direction of bind/connect is independent of the pattern used on top; thus a PUB socket can be connected to a SUB socket that has been bound to an interface (whereas the other way round might feel more natural).
The other thing that I think a lot of people don't realise is that you can bind (or connect) sockets more than once, to different transports. So a PUB socket can quite happily send to SUB clients that are both local in-process threads, other processes on the same machine via ipc, and to clients on remote machines via tcp.
There are other things that you can do. If you use the ZMQ_FD option from here, you can get ZMQ_EVENT notifcations in some way or other (I can't remember the detail) which will tell you when the underlying connection has been successfully made. Using the file descriptor allows you to include that in a zmq_poll() (or some other reactor like epoll() or select()). You can also exploit the heartbeat functionality that a socket can have, which will tell you if the connection dies for some reason or other (e.g. crashed process at the other end, or network cable fallen out). Use of a reactor like zmq_poll(), epoll() or select() means that you can have a pure actor model event-driven system, with no need to routinely check up on status flags, etc.
Using these facilities in ZMQ allows for the making of very robust distributed applications/system that know when various bits of themselves have died, come back to life, taken a network-out holiday, etc. For example, just knowing that a link is dead perhaps means that a node in your distributed app changes its behaviour somehow to adapt to that.

Using a ServerStreaming rpc call for long running notifications channel

I am thinking about using a gRPC service to facilitate notifications between two services. (as an aside, I will be using protobuf-net/ protobuf-net.Grpc) The intent is that the client service would establish and maintain a connection to the server service, and react to notifications over time. In an perfect technology world where there are no network blips, no server restarts, etc the idea would be to establish this connection once and have that server streaming call live for the lifetime of the application. Obviously in the real world we need to deal with retries, reconnects, fail-overs etc.
My question is: Is calling a server streaming call in grpc and keeping the call open for long periods of time an appropriate use of server streaming calls, or is it an abuse of that feature?
This is a perfectly fine use case for gRPC. gRPC is designed for this kind of use.
Yes, you have to deal with reconnections or more exactly reestablishment of streams when the connection to the server dies.

Reusing socket handle

We have a legacy vb6 automation application that communicate over a sockets on need basis.
But opening and establishing connection (only when required) to the remote port taking more time frequently.
So,i am planning to write other application (say a socket server) that opens the required sockets and keep the connections alive.This application will write connected socket handle values to a file or database.
Is it possible in vb6 to create a socket object using socket handle from the already opened socket that was owned by other process (socket server application in this case)?
This is exactly the type of situation that WSADuplicateSocket() is intended for.
Your "server" can create a socket and use WSADuplicateSocket() to fill a WSAPROTOCOL_INFO record that describes the socket. The "server" can then expose the WSAPROTOCOL_INFO to your VB app using any IPC mechanism you want. The VB app can pass the WSAPROTOCOL_INFO to WSASocket() to access the socket and use it as needed.
No, Windows sockets cannot be shared cross-process, not even through handle inheritance (this is because although it is usually a handle, an LSP might return something that is not a handle and thus not inherited). You should make one process open and maintain the connection and the others talk to that process to communicate with the server.

Game server with ZMQ sockets

I tried to write a game server with ZMQ sockets. The server is using a ZMQ_REP socket and the client a ZMQ_REQ socket.
This works only if one client is connected. If I connect a second client then communication breaks between the server and the first client.
Which server <-> client pattern works for one server and multiple clients?
for servers, you want to use ROUTER, and for clients, DEALER. There are a lot of examples of this in the ZeroMQ Guide. It's worth reading through that (or buy the book) and learning the different patterns, as you try simple models of your own. Don't try to build anything too complex to start with.

Can I open a Netty Client Channel on a local port binded by a Netty server in order to perform hole punching?

Here is the problem: I'm trying to send a message from a Netty Server binded port to perform hole punching. I have read many things about it, especially that on unix it is not possible. This would really simplify my code though and take a load off the main server, which wouldn't have to relay as many InetAddresses back and forth. I have tried using a ConnectionLess bootstrap too which didn't work.
Java throws an UnsupportedException on my Mac.
I'm using netty 3.6.5. Would there be a way to do it in Netty 4.0.0?
Thank you all in advance.

Resources