I have look through the code of Nginx on Windows version.
But I don't understand how master is sharing listening sockets with workers.
It is straight forward on Linux. When it fork(), workers inherit the file descriptions from the master.
But when it comes to the Windows version, in the CreateProcess() function, it specify the "bInheritHandles" argument field as "0", meaning it does not inherit the handles!
So then how the workers share listening sockets with master?
I did read the code for two days just to find the answer to this question.
But I still can not understand it.
Thanks!
*This question looks very similar with the another one How does nginx worker process share the 'listen socket'
But it is not. Because that one is asking about the one on Linux platform.
It doesn't. Instead, on Windows each nginx worker process creates its own listening sockets, and uses them to accept connections.
Creating listening sockets on the same ports is possible as nginx uses setsockopt(SO_REUSEADDR) on listening sockets, and this allows completely duplicate listening sockets on Windows.
Only one of these duplicate listening sockets actually work though, and here comes the first limitation of nginx for Windows as listed in the documentation:
Although several workers can be started, only one of them actually does any work.
Note well that nginx for Windows "is considered to be a beta version".
Related
I have a webhook URL and a normal web server (running HapiJS).
I'd like to proxy certain requests in HapiJS to the webhook server that's running on a private port but I need to know what the $PORT is on the other non web process.
Is there a way to find this port number?
There is no way to find that port number.
Heroku dynos run on different runtimes. So even if you did know it, you would also need to figure out the IP address of that server, which would change with every deployment and once every 24 hours.
This would also not be very scalable, as the strength of heroku is to allow you to boot more dynos easily. If you rely on knowing where the other dyno is, you're losing that easy scaling.
You don't necessarily need this to communicate between processes though. Using a redis queue, you could enqueue asynchronous jobs to be processed by your worker process. Both processes would communicate, and they wouldn't need to know where the other one is.
I have to set sails app where I can have socket.io connections on multiple ports - for example authentication on port 3999 and data synchronization on port 4999.
Any way to do so ?
I asked a similar question yesterday and it seems that yours is also similar to mine, here's what I'm going to implement.
Given that you will have multiple instances that are going to work on different ports, they won't be able to talk to each other directly and that breaks websocket functionality.
It seems that there are multiple solutions to this (sticky sessions vs using the pub/sub functionality of Redis), I chose Redis. There's a module for that called socket.io-redis. You also need emitter module, it's here.
If you choose that route, no matter how many servers (multiple servers with multiple instances) OR many instances on a single server you run your app on, it will function without a problem thanks to Redis.
At least that's what I know for now, been searching for a few days, haven't tried it yet.
Not to mention, you can use Nginx for load balancing, like below. (Copied from socket.io docs)
upstream io_nodes {
ip_hash;
server 127.0.0.1:6001;
server 127.0.0.1:6002;
server 127.0.0.1:6003;
server 127.0.0.1:6004;
}
We have been trying - without success - to get transactional message queues working between local servers and our cloud servers up in Amazon EC2.
We're using NServiceBus, and have got the pub/sub examples and various other trivial apps working locally between here and EC2, but trying to spin up the components of our actual application is proving... vexatious.
As far as I can work out, to allow a local server (DYLAN-PC) to send a message transactionally via a queue on an Amazon EC2 instance, I will need to:
Enable NETBIOS name resolution (e.g. via the /etc/lmhosts file) at both ends
Allow RPC connections to be initiated from either end (so open port 135 for RPC plus various other ports)
Configure MSTDC on both systems, enabling remote connections and inbound/outbound connections
Have I missed something? In particular, the requirement to allow NetBIOS in an age where everything (including Active Directory!) runs on DNS seems particularly archaic. Are we doing something stupid trying to use MSMQ between sites like this? This is the first big project where we've tried this kind of distributed architecture, and the deployment/configuration is starting to hurt so much I'm convinced we've taken a wrong turn somewhere... a little perspective or advice would be gratefully received!
If you're look to build a geographically distributed system, where you can't arrange a VPN between these sites, you should be using the gateway capabilities of NServiceBus to communicate over alternate transports (like HTTP) between those sites.
RPC is required for reading from remote queues.
If you push to remote queues and pull from local queues, you won't be using RPC.
That is to say, if I have a server listening on 127.0.0.1, and a TCP connection comes in, how can I determine the process id of the client?
Also if there isn't an API for this, where would I be able to extract the information from in a more hackish manner?
(The purpose of this is to modify a local HTTP proxy server to accept or deny requests based on the requesting process.)
Edit: palacsint's answer below led me to find this answer to a similar question which is just what's needed
netstat -a -o
prints it. I suppose they are on the same machine becase you are listening on 127.0.0.1.
The only way to do this is if the connecting process sends some sort of custom headers which contains identifier. This is due to the fact that the networking layer is completely separated from the application layer (hint: OSI MODEL. This way it is possible to write lower layers software without caring what happens above as long as the messages exchanged (read: networking packets) follow a pre-determined format (read: use the same protocol).
I have a small application, which is free for personal use, but requires a paid license for corporate use.
It is most likely that in a corporate environment my application will run on multiple workstations. If it is the freeware version, I want to show an unobtrusive message. (and continue)
It doesn't have to be bulletproof, if it is not possible (i.e. firewall) then the application should just continue. And I don't want to make the user set up some kind of central service to track the instances. I don't want to annoy my users (especially not the paying ones *g*)
Is there any way to achive this kind of functionality?
I remember an older version of Dreamweaver had this kind of feature. You couldn't run it more than once in the same network.
One way: Listen for UDP broadcast on specific ports. Let each instance send broadcast UDP packet on this port to local network. If application receives such packet, and recognizes its structure, it knows that other instance is running.
You can include license details to avoid messages if two valid licenses are used.
Broadcasts usually aren't routed, so this works on local network only. (And user can disable it completely via firewall too... but if you will use some standard port like 53 (DNS), it won't be blocked).
Other way is to use custom server, which is informed about all running instances around the world ;-)
There are two primary ways to achieve this:
First, you can set up a small server application on each workstation that communicates with other workstations on the network (personally I would use Bonjour for discovery, but there are other options). The drawback here is that you're going to write quite a bit more code to make this work than option #2.
Second (probably simpler) would be to use WMI to enumerate processes on other workstations (again, probably use a Bonjour-like system for discovery), and find your process running on other machines. The drawback to this is that your enumeration code will require privileges on all machines to conduct the search.
When the application starts, it sends out a UDP broadcast on a specific port. This will be restricted to the local subnet, and might not make it through firewalls. This is the "is anyone else running, or can I start?" query.
If there are no responses, the application starts as normal, listening for this UDP broadcast. If it sees one, it responds with an "I'm already running; you can't start" packet.
The application that's just started receives this response packet and then refuses to start or (if you don't want to be that strict) displays a warning to the user.
You'd want to include the product ID and license key (or a hash) in the initial request, so that you can have more than one license on the same network. The response probably wants the machine name in it, so that the second user can go and find the first user and ask if they really need to use the application.
Evil corporation solution:
Have the application call home every time it starts. If more than one application for a license wakes up, tell it not to. If there is no internet connection, don't start at all.