I need some help on my problem : I am working in a windows 2019 server environment.
I have a solution in place that require a connected protocol between client and server : a socket is opened on TCP/IP and the client start a session then there is a dialog between the client and the server : the dialog is always initiated by the client. The client act also as a server because it expose a service over internet that require to open and close the socket during a session of pin verification. Here a current logical view of my system in place :
As there is a need to have a connected socket between my client and my BE Service, I am forced to have an affinity in place : I am searching a way to make ANY of my two clients able to issue commands to my BE service and receive response as if they were connected via a persistent socket. I need a solution that do not introduce a SPOF : for example I was thinking in using a HA PROXY but if there is a problem with it I could loose all my BE services. The question is : is there anyway to put in place a mediator between my clients and my BE services so that any client could emit command and receive response on a existing opened session and also preverve hight avaibility of my system ?
The final solution would be something like that :
Related
I'd like to make a video call app using WebRTC on Unity. I have investigated almost of the WebRTC services and found out that the WebRTC services require "my own server" for authentication(to give users privileges to access the server). Some companies even say "no server needed" but I actually had to register my server domain to use their services - sounds weird...
my questions are :
why do we need to prepare server (It seems the service provider could have prepared auth servers as well)
Is there any WebRTC service as a complete sever bundle(really woking with client-side app only)
Thanks.
For webrtc you need at at least to exchange the candidate between the peer to allow them to connect (it's called signaling int the webrtc architechture), you also need server to handle network path if nat doesn't allow it (stun/turn server).
There is a lot of server and client depending on your use case complexity and stack. (kurento, Freeswitch, peerJs server ... )
I'm building a message broker which communicates with clients over ZeroMQ PUSH/PULL sockets and has the ability to exclude clients from messages they're not subscribed to from the server side (unlike ZeroMQ pub/sub which excludes messages on the client side).
Currently, I implement it in the following way:
Server: Binds ZeroMQ PULL socket on a fixed port
Client: Binds a ZeroMQ PULL socket on a random or fixed port
Client: Connects to the server's PULL socket and sends a handshake message containing the new client's address and port.
Server: Recieves handshake from client and connects a PUSH socket to the client's PULL server. Sends handshake response to the client's socket.
Client: Recieves handshake. Connected!
Now the client and server can communicate bidirectionally and the server can send messages to only a certain subset of clients. It works great!
However, this model doesn't work if the clients binding PULL sockets are unable to open a port in their firewall so the server can connect to them. How can I resolve this with minimal re-architecting (as the current model works very well when the firewall can be configured correctly)
I've considered the following:
Router/dealer pattern? I'm fairly ignorant on this and documentation I found was sparse.
Some sort of transport bridging? The linked example provides an example for PUB/SUB.
I was hoping to get some advice from someone who knows more about ZeroMQ than me.
tl;dr: I implemented a message broker that communicates with clients via bidirectional push/pull sockets. Each client binds a PULL socket and the server keeps a map of PUSH sockets so that it can address specific subscribers. How do I deal with a firewall blocking the client ports?
You can use the router/dealer to do this like you say. By default the ROUTER socket tracks every connection it has. The way it does this is by having the caller stick the connection identity information in front of each message it recieves. This makes things like pub/sub fairly trivial as all you need to do is handle a few messages server side that the DEALER socket sends it. In the past I have done something like
1.) Server side is a ROUTER socket. The ROUTER handles 2 messages from DEALER sockets SUB/UNSUB. This alongside the identity info sent as the first part of a frame allows the router to know the messages that a client is interested in.
2.) The server checks the mapping to see which clients should be sent a particular type of data using the map and then forwards the message to the correct client by appending the identity again to the start of the message.
This is nice in that it allows a single port to be exposed on the server. Client side we do not need to expose ports, simply just connect to the server ROUTER socket.
See https://zguide.zeromq.org/docs/chapter3/ for more info.
I want to use this as a proxy server to connect many different clients with servers. Here is what I'm looking to do:
The server software on a user's computer would connect to a proxy server that is running on a VPS. It would pass in some kind of Key or authentication info to identify itself and then would maintain a persistent TCP connection to the proxy server.
A client application running on a mobile device or other computer would connect to the proxy server and pass in some kind of Key or authentication info. The proxy server would match the connection between the client and server based on their authentication info, and then forward all data back and fourth between the connections.
The proxy server would need to be able to handle multiple clients and servers connecting to it at once and use the authentication info to pair them up. There could be multiple clients connecting to the same server at the same time too. The connection from the client and server would both be outbound so that they are not blocked by firewalls. I wrote the client and server software, so I can make them work with any specific proxy.
What is the name of this kind of proxy server? And can anyone recommend any?
Thanks!
When deploying a web application running on a traditional web server, you usually restart the web server after the code updates. Due to the nature of HTTP, this is not a problem for the users. On the next request they will get the latest updates.
But what about a WebSocket server? If I restart or kill the old process all connected users will get disconnected. So my question is, what kind of strategy have you used to deploy a WebSocket server smoothly?
You're right, every connected user will be disconnected if the server restarts.
I think the less bad solution is to tell to the client to reconnect in the onClose method of the client.
WebSockets is just a transport mechanism. Libraries like socket.io exist to build on that transport -- and provide heartbeats, browser fallbacks, graceful reconnects and handle other edge-cases found in real-time applications.
In our WebSocket-enabled application, socket.io is central to ensuring our continuous deployment setup doesn't break users' active socket connections.
If clients are connected directly to sever that does all sockets networking and application logic, then yes - they will be disconnected, due to TCP layer that holds connection.
If you have gateway that clients will be connecting to, and that gateway application is running on another server, but will communicate and forward messages to logical server, then logical server will send them back and gateway will send back to client responses. With such infrastructure, you have to implement stacking of packets on gateway until it will re-establish connection with logical server. Logical server might notify gateway server before restart. That way client will have connection, it will just wont receive any responses.
Or you can implement on client side reconnection.
With HTTP, every time you navigate away, browser actually is creating socket connection to server, transmits all data and closes it (in most cases). And then all website data is local, until you navigate away.
With WebSockets it is continuous connection, and there is no reconnection on requests. Thats why you have to implement simple mechanics when WebSockets getting closing event, you will try to reconnect periodically on client side.
It is more based on your specific needs.
I have a server and client program on the same machine. The server is part of an application- it can start and stop arbitrarily. When the server is up, I want the client to connect to the server's listening socket. There are win32 functions to wait on file system changes (ReadDirectoryChangesW) and registry changes (RegNotifyChangeKeyValue)- is there anything similar for network changes? I'd rather not have the client constantly polling.
There is no such Win32 API, however this can be easily accomplished by using an event. The client would wait on that event to be signaled. The server would signal the event when it starts up.
The related API that you will need to use is CreateEvent, OpenEvent, SetEvent, ResetEvent and WaitForSingleObject.
If your server will run as a service, then for Vista and up it will run in session 0 isolation. That means you will need to use an event with a name prefixed with "Global\".
You probably do have a good reason for needing this, but before you implement this please consider:
Is there some reason you need a connect right away? I see this as a non issue because if you perform an action in the client, you can at that point make a new server connection.
Is the server starting and stopping more frequently than the client? You could switch roles of who listens/connects
Consider using some form of Windows synchronization, such as semaphore. The client can wait on the synchronization primitive and the server can signal it when it starts up.
Personally I'd use a UDP broadcast from the server and have the "client" listening for it. The server could broadcast a UDP packet every X period whilst running and when the client gets one, if it's not already connected, it could connect.
This has the advantage that you can move the client onto a different machine without any issues (and since the main connection from client to server is sockets already it would be a pity to tie the client and server to the same machine simply because you selected a local IPC method for the initial bootstrap).