I want to send HTTP request after calling ExitBootServices() in UEFI environment. Maybe I need to start the operating system waiting for networking, so I wrote a DXE_RUNTIME_DRIVER, but I do not know how to send HTTP requests. Does anybody know how to do that?
Related
I'm using Rebus (https://github.com/rebus-org (v.0.83)) and until now it's been all local to a single machine. Now I need to use a remote queue from my website to an app server. It's not abundantly clear to me how to set this up with Rebus. A few questions
I guess I need MSMQ on both machines (web & app) correct? I've configured the web site to UseMsmqInOneWayClientMode;
or is there a way to specify to send it over http?
My configuration looks like this more or less. I'm guessing that inputQUeue needs to point to the local machine not the remote one right?
<rebus inputQueue="mywebqueue" errorQueue="MyErrorQueue#mymachine" workers="1" maxRetries="5">
<endpoints>
<add messages="MyLibrary.CreateMessage, MyLibrary" endpoint="MyQueue#mymachine"/>
</endpoints>
</rebus>
Help would really be appreciated.
Yes. All machines that need to use MSMQ somehow, need to have MSMQ installed. Even as a one-way client, like your webserver, because MSMQ achieves its high availability by providing outgoing queues when you send to remote machines.
I think so. I've never used MSMQ beyond its basic reliable messaging capabilities. Google around, I bet you can find something ;)
Your configuration looks right. And yes - input queues are always local, whereas queues you send to (error queue and all endpoints specified in the endpoint mappings) can be remote too.
I want to create a XMPP server on my network and then send message to it with python so that this server can restart the target computer on the network , now how can i set up this server and how can i do the rest of the process?
tnx
I am not sure in what context you are trying to do this, but XMPP has been used in context outside of usual chat and instant messengers (e.g. load balancers, rpc, ...).
There can be several ways of doing this. One way I can think right now is by using Jabber RPC xep-0009 which says:
This specification defines an XMPP protocol extension for
transporting XML-RPC encoded requests and responses between two XMPP entities.
The protocol supports all syntax and semantics of XML-RPC except that
it uses XMPP instead of HTTP as the underlying transport.
Workflow wise here is how you can make this work:
You will need a jabber server which is up and running say on host-A
You will need to configure a startup service on other hosts in the network (say on host-B, host-C, host-D). This startup service is nothing but a xmpp client daemon which will start in the background whenever host is started.
This xmpp client configured as startup service are special in the sense that they will accept incoming rpc calls (support for XEP-0009) and execute received commands on the host.
Received RPC commands can be synonymous to shutdown, kill -9 xxxx depending upon your specific needs.
Finally, xmpp client on host-C can send one or more commands wrapped inside an stanza to xmpp client running on host-B.
You can use one of the existing python xmpp client library and simply extend their working examples for your use case. You will also need to check details on how to configure startup service depending upon your Operating System (e.g. update-rc.d for ubuntu or sc.exe for windows)
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.
An external application will send HTTP POST request to multiple HTTP/HTTPS servers (e.g. 10 HTTP servers). These HTTP servers may get almost same HTTP Post request. These HTTP servers will analyze the data and send 200 OK response if data validation pass.
I am having all these HTTP servers listening on single host with different ports.
Please suggest me some way to achieve it.
FYI - This request response between Application and HTTP Server(s) will happen only once and then HTTP server will be closed.
I am thinking to implement it using forking the HTTP:Daemon 10 times but looking forward for some light solution.
Also I am thinking to capture these data through a single interface rather then checking the data from all 10 individual 10 HTTP server.
for PORT in `seq 11111 11121` ; do plackup -Ilib --listen :$PORT app.psgi & done
For example http://www.utorrent.com/testport?port=12345
How does this work? Can the server side script attempt to open a socket?
There are many ways of accomplishing this through server-side scripting. As #Oded mentioned, most server-side handlers are capable of initiating socket connections on arbitrary ports, and most of those even have dedicated port-scanning packages/libraries (PHP has one in the PEAR repository, Python's 'socket' module makes this type of tasks a breeze, etc...)
Keep in mind that on shared host platforms, socket connections are typically disabled for security purposes.
Another way that is also very easy to accomplish is to use a command-line port-scanner such as nmap from your server-side script. i.e in PHP, you would do echo ``nmap -p $port $ip\
The server side script will try to open a connection on the specified port to the originating IP.
If there is no response (the attempt will timeout), this would be an indication that the port is not open.
The server can try, as #Oded said. But that doesn't ensure the receiver will respond.
Typically, something like this happens:
The URL request contains instructions about which port to access. The headers that your browser sends include information about where the request is originating from.
Before responding to the request, the server tries to open a port and checks if this is successful. It waits a while before timing out.
The webpage is rendered dynamically based on the results of this test.
The response is returned to you containing the results.
Sometimes steps (2) and (3) will be replaced with an AJAX callback, which allows the response to return sooner.