Is it possible to have multiple servers in gRPC and choose from them dynamically?
I'm looking for a solution that connects a central server to several servers on the Internet and detects which server to run the received task dynamically
One way is to make the central server a proxy, and forward requests to the real servers.
If the services are the same, the proxy can do roundrobin, or other algorithms, and it basically becomes a load balancer.
If the services are different, the proxy can forward based on host name (https://en.wikipedia.org/wiki/Virtual_hosting), or based on the RPC service+method.
Related
I made a proxy server in python 3. It listens on the port 4444. It basically receives the request from clients and sends it to the server. I want to use it as a firewall to my Dvwa server. So added another functionality to the proxy. What it does is, before sending the request to the DVWA server, it validates the input.
But the problem is, the clients have to configure their proxy settings in the browser to use my proxy server. Is there any way to access the proxy without configuring the browser settings. Basically I want to host the proxy server instead of the original web server. So that all the traffic goes through the proxy before going to the webserver.
Thanks in advance...
You don't say whether your Python3 proxy is hosted on the same machine as the DVWA.
Assuming it is, the solution is simple: a reverse-proxy configuration. Your proxy transparently accepts and forwards requests to your server who then processes them and sends them back via the proxy to the client.
Have your proxy listen on port 80
Have the DVWA listen on a port other than 80 so it's not clashing (e.g. 8080)
Your proxy, which is now receiving requests for the IP/hostname which would otherwise go to the DVWA, then forwards them as usual.
The client/web browser is none the wiser that anything has changed. No settings need changing.
That's the best case scenario, given the information provided in your question. Unfortunately, I can't give any alternative solutions without knowing the network layout, where the machines reside, and the intent of the project. Some things to consider:
do you have a proper separation of concerns for this middleware you're building?
what is the purpose of the proxy?
is it for debugging/observing traffic?
are you actually trying to build a Web Application Firewall?
In server-side load balancing, the clients call an intermediate server, which then decides which instance of the actual server (or microservice) to call.
In client-side load balancing also, the clients call an intermediate server (the API gateway - Zuul for instance, configured with a load-balancer - Ribbon for instance and a naming server - Eureka for instance), which then decides which instance of the microservice to call.
Unless we include the API gateway as part of the client, the client still doesn't know the IP address of the exact server to which it should send the request. Seems to me, to be a lot like server-side load-balancing. Is there something I'm missing?
(Including the API gateway as part of client seems weird, since its usually deployed on a different server from the client)
In Client Side load balancing, the Client is doing the heavy lifting of discovery and connection to the origin server. The client may reference a lookup (Eureka, Consul, maybe DDNS), to discover what the end destination is and the registry will dole out a valid origin. The communication is direct, client to server without a middle man.
In Server Side load balancing, the client is dumb, and makes a call to a predetermined address (usually DNS or static IP). That device then either proxies (TCP or protocol level) the connection to the origin server based on either a lookup, heartbeat, etc.
I've seen benefits in client side routing in that as long as you have IP connectivity between client and server, the work of the infrastructure is trivial to add new services, locations, products, apps, etc. As long as the new server can "register" with the registry, and the client has IP access to the server, it just works and IT does not have to be involved in rolling out your new service.
The drawback is it makes the client a little more heavy, it does require IP access direct from client to server, and may be confusing for traditional IT folks and auditors. Each client needs to be aware of the registry and have code to make calls (or use a sidecar/sidekick).
I've seen it in practice where a group started to transition their apps to a Docker environment, and they were able to run their Docker based apps along side their non-docker versions at the same time w/o having to get IT involved and do a lot of experimentation and testing quickly and autonomously.
If you have autonomous teams, are highly advanced on the devops spectrum, and have a lot of trust with your teams, Client Side routing and load balancing may be a good experience for you.
This may not be the correct place for this question as it's part networking, but here goes.
I am wanting to put together a WebApi (using the ASP.NET MVC WebApi framework) to be consumed by client machines external to our network. However the client machines resolve web traffic through a proxy server for which our software does not have authentication. We have noticed that outgoing FTP connections are possible though.
So I am wondering whether we can host the webapi and have client machines connect out through Port 21? Does that even make sense? Sorry if it's a stupid question.
I managed to find some answers and thought I would share for anyone that might be interested.
Binding WebApi to ports other than 80
This is possible, but tricky. When you publish the Api project onto IIS (or wherever you are hosting it) you just bind it to an alternative port. You then also make sure you forward that port in your router. Then, clients of the API just specify the host using your custom port to access the endpoint through that port: http://myhostname.com:21/api/values or whatever.
Complications
Testing the endpoints can be tricky as Chrome blocks HTTP traffic being sent via some ports - port 21 is one such port. So to test it you need to write a client exe that can hit the endpoints to make sure they are working (like a console application).
Despite figuring all of this out, I still could not connect out through the firewall. I suspect that some configuration is blocking the traffic because even though it is going out through an open port (21), it is not FTP traffic: it's HTTP traffic.
A Solution
It occurred to me that SOAP operates through a range of protocols (FTP, SMTP, HTTP, to name a few) and formats its messages as XML. So in this scenario it would make more sense to use a SOAP service via Port 21 rather than REST which is strictly HTTP.
I need clarification on the buzzword "Proxy-Aware". Does it mean that a proxy is sensed after the app attempts to directly perform a operation with a host? Or is it that after the creation of a proxy object (think .net WebProxy) and passing in proxy address, port, login etc.., the app knows how create and use the proxy connection to the server?
I think the word means if the application is able to establish connections to one or more proxy servers to reroute your connection attempt to target hosts through these proxy servers.
E.g. web browsers(proxy-aware) with proxy settings connects to the proxy server first and requests the proxy server to connect to your requested web page, but most terminal clients does not support proxy setting and can not perform such a process and thus are not proxy-aware.
After sifting through a few postings looking for a definition, I have come up with the definition for myself. "A proxy aware app is an app such that given a address (and/or creds) to a proxy as well as the destination address, the app will create the proxy connection and will manage the software side of the traffic between client, proxy connection and the destination." I conclude that a necessary condition to be a proxy-aware app is NOT the ability to sense a proxy but the ability to accept and manage the fact that there is an intermediate, addressable hop between client and destination.
The WebSocket standard hasn't been ratified yet, however from the draft it appears that the technology is meant to be implemented in Web servers. pywebsocket implements a WebSocket server which can be dedicated or loaded as Apache plugin.
So what I am am wondering is: what's the ideal use of WebSockets? Does it make any sense to implement a service using as dedicated WebSocket servers or is it better to rethink it to run on top of WebSocket-enabled Web server?
The WebSocket protocol was designed with three models in mind:
A WebSocket server running completely separately from any web server.
A WebSocket server running separately from a web server, but with traffic proxied to the websocket server from the web server (allowing websocket and HTTP traffic to co-exist on the same port)
A WebSocket server running as a plugin in the web server.
The model you pick really depends on the application you are trying to build and some other constraints that may limit your choices.
For example, if your application is going to be served from a single web server and the WebSocket connection will always be back to that same server, then it probably makes sense to just run the WebSocket server as a plugin/module in the web server.
On the other hand if you have a general WebSocket service that is usable from many different web sites (for example, you could have continuous low-latency traffic updates served from a WebSocket server), then you probably want to run the WebSocket server separate from any web server.
Basically, the tighter the integration between your WebSocket service and your web service, the more likely you will want to run them together and on the same port.
There are some constraints that may force one model or another:
If you control the server(s) but not the incoming firewall rules, then you probably have no choice but to run the WebSocket server on the same port(s) as your HTTP/HTTPS server (e.g. 80 and 443). In which case you will have to use a web server plugin or proxy to the real WebSocket server.
On the other hand, if you do not have super-user permission on the server where you are running the WebSocket server, then you will probably not be able to use ports 80 and 443 (below 1024 is generally a privileged port range) and in that case it really doesn't matter whether you run the HTTP/S and WebSocket servers on the same port or not.
If you have cookie based authentication (such as OAuth) in the web server and you would like to re-use this for the WebSocket connections then you will probably want to run them together (special case of tight integration).