I am working on a way to force the game Alien vs. Predator 2 to connect to specific IP address. The reason is, that quite often the server is reachable, but the UDP broadcast the game sends to discover it do not reach the server.
On localhost, this kind of discovery always works. So what I thought I could do is a simple console application that will listen on UDP broadcast from the game and reply. The reply needs to look like it came from the real server's IP, not localhost.
I figure that with no ISP/firewalls involved, this should be much simpler.
I read Node.JS UDP dgrams documentation. It says how to specify target address and port for a message, but it seems to rely on OS' behavior for filling up the source IP and port.
Is there another way?
You can try adding a line to your operating system host file:
127.0.0.1 **the_original_game_server_ip**
This will redirect all traffic to localhost instead of the game server.
Now just create a console application that listens to the game server port.
I have built a website with PHP + Apache + JS + HTML 5. Now there is a point where I have to tell the user every second if the server is connected and ready to receive data and/or internet connection is lost/available or whatever else which can tell the user to not to send data to server because of unavailability of Server or internet connection.
For this purpose I can either move to Long Polling with Ajax and keep pinging my server every second but surely this will cause alot of network overhead on my Apache Server where my clients are about tens of thousands live at a time so keep pinging the server is not a good option. Therefore, I decided to use WebSockets.
I have been googling for about 2 days but yet could not find enough good article to answer my 3 basic questions regarding WebSocket and Apache + PHP.
1) If once the WebSocket connection is made with server, then does it remain active like Long Polling with Server or what is the mechanism behind it? I mean how does WebSocket maintain its relation with server does it keep polling with server and hence there is always a connection between Client and Server?
2) If your answer to above question is yes then what network/IO overhead would be on server side if I use websockets because there is a continuous connection between Client and Server. And imagine if there are hundreds of thousands of clients online at a time what load will it create on Server Network or IO?
3) What is the Best approach to use WebSockets when using Apache + PHP on server? Any good article on this where I can study how to communicate with Apache Server using WebSockets? I found this question, but it doesn't answer well Using WebSocket on Apache server. In this question, it limits the experts to not to include any answer which has sysadmin tools, while I am asking for it if any required.
I have a VPS Server so tunning and installing some tools isn't a problem.
Any help would be highly appreciated. Thanks with Regards.
1) If once the WebSocket connection is made with server, then does it remain active like Long Polling with Server or what is the mechanism behind it? I mean how does WebSocket maintain its relation with server does it keep polling with server and hence there is always a connection between Client and Server?
Yes, it remains active and there is always a connection between Client and Server. However, the client needs to maintain the connection and on connection exceptions. In this case, it is your javascript code.
2) If your answer to above question is yes then what network/IO overhead would be on server side if I use websockets because there is a continuous connection between Client and Server. And imagine if there are hundreds of thousands of clients online at a time what load will it create on Server Network or IO?
WebSocket connections are handled on TCP/IP level and by definition, they are not resource consuming operations when there is no data going through the TCP tunnel. So rather than worrying about your CPU and memory conception, you need to worry about the limit on the number of connections. Consider using a load balancer for your socket connections and utilize multiple servers if you are expecting more than 10000 concurrent connections.
3) What is the Best approach to use WebSockets when using Apache + PHP on server? Any good article on this where I can study how to communicate with Apache Server using WebSockets? I found this question, but it doesn't answer well Using WebSocket on Apache server. In this question, it limits the experts to not to include any answer which has sysadmin tools, while I am asking for it if any required.
For such a use case of yours - getting the status of the server, I would suggest using a message broker rather than load this simple operation to Apache.
Please consider looking at mosquitto, hivemq or rabbitmq
All of them are supporting WebSockets and all of them have their pros and cons. Do the small proof of concepts over them and choose what is best for you.
I have a c# tcp server, I want to connect to the server via a html client page.
The problem: There is no simple way to create TCP sockets in Javascript on a browser side. Although solutions like Websockets allow to create something that resemble sockets, you can use them to connect only to servers that support Websockets. Not to any random servers that know nothing about HTTP.
so is there a solution to connect to my srver.
No. There just isn't. The browser is a tightly locked down environment. The only socket connection that you can open from JavaScript is WebSocket. Since it's your server, adding WebSocket support shouldn't be too complicated, and there are WebSocket libraries available for C#.
Maybe someone else will have an idea for you, but...
The best solution I can think of is for your server to support websockets.
The situation you described - along with connectivity issues for traffic passing through proxies and routers - is one of the reasons Websockets were introduced in the first place.
Bare in mind that Websockets can send and receive binary data. It's just that javascript make it more comfortable to write text based messages.
Also, many NAT routers, Proxies and firewalls will block raw TCP/IP communication while allowing Http communication to pass through. This is why you have a better chance at connection establishment and retention when implementing the Websocket protocol.
I'm running a game which contains a server.js backend (which is hosted and run on my localhost), and the frontend is on a github website. The github page connects to the server on my localhost through the config which points to 127.0.0.1. I realize that I will be able to play this from my localhost this way, but will other people be able to?
Basically the index.html connects to the visitor's localhost to look for the running server.
A visual representation (sort of):
[nullwalker.github.io/index.html] ----> [localhost(127.0.0.1)/server.js]
What should I do to allow myself to play from the computer that's hosting the server backend as well as others being able to play?
You would need to host it in a live environment. There are ways via port forwarding to use your computers ip (gateway) to allow others to connect, however typically ISP's will try to stop you from using your dynamic IP statically. Safest bet is to launch a cheap VPS and host it there.
http://www.howtogeek.com/66214/how-to-forward-ports-on-your-router/
This article seems to explain port forwarding well enough.
As for the VPS, you can find extremely cheap ones really easily, if you do not expect a lot of players it should be fine, if you expect more then using your own connection is dangerous.
unless they have the same server running on their localhost, no. And they almost surely don't. You should get a host (digitalocean.com is very popular and good, but there are many others), and then run it there and connect to that instead of localhost
I currently try to implement a simple HTTP-server for some kind of comet-technique (long polling XHR-requests). As JavaScript is very strict about crossdomain requests I have a few questions:
As I understood any apache worker is blocked while serving a request, so writing the "script" as a usual website would block the apache, when all workers having a request to serve. --> Does not work!
I came up with the idea writing a own simple HTTP server only for serving this long polling requests. This server should not be blocking, so each worker could handle many request at the same time. As my site also contains content / images etc and my server does not need to server content I started him on a different port then 80. The problem now is that I can't interact between my JavaScript delivered by my apache and my comet-server running on a different port, because of some crossdomain restrictions. --> Does not work!
Then I came up with the idea to use mod_proxy to map my server on a new subdomain. I really don't could figure out how mod_proxy works but I could imagine that I know have the same effect as on my first approach?
What would be the best way to create these kind of combination this kind of classic website and these long-polling XHR-requests? Do I need to implement content delivery on my server at my own?
I'm pretty sure using mod_proxy will block a worker while the request is being processed.
If you can use 2 IPs, there is a fairly easy solution.
Let's say IP A is 1.1.1.1 and IP B is 2.2.2.2, and let's say your domain is example.com.
This is how it will work:
-Configure Apache to listen on port 80, but ONLY on IP A.
-Start your other server on port 80, but only on IP B.
-Configure the XHR requests to be on a subdomain of your domain, but with the same port. So the cross-domain restrictions don't prevent them. So your site is example.com, and the XHR requests go to xhr.example.com, for example.
-Configure your DNS so that example.com resolves to IP A, and xhr.example.com resolves to IP B.
-You're done.
This solution will work if you have 2 servers and each one has its IP, and it will work as well if you have one server with 2 IPs.
If you can't use 2 IPs, I may have another solution, I'm checking if it's applicable to your case.
This is a difficult problem. Even if you get past the security issues you're running into, you'll end up having to hold a TCP connection open for every client currently looking at a web page. You won't be able to create a thread to handle each connection, and you won't be able to "select" on all the connections from a single thread. Having done this before, I can tell you it's not easy. You may want to look into libevent, which memcached uses to a similar end.
Up to a point you can probably get away with setting long timeouts and allowing Apache to have a huge number of workers, most of which will be idle most of the time. Careful choice and configuration of the Apache worker module will stretch this to thousands of concurrent users, I believe. At some point, however, it will not scale up any more.
I don't know what you're infrastructure looks like, but we have load balancing boxes in the network racks called F5s. These present a single external domain, but redirect the traffic to multiple internal servers based on their response times, cookies in the request headers, etc.. They can be configured to send requests for a certain path within the virtual domain to a specific server. Thus you could have example.com/xhr/foo requests mapped to a specific server to handle these comet requests. Unfortunately, this is not a software solution, but a rather expensive hardware solution.
Anyway, you may need some kind of load-balancing system (or maybe you have one already), and perhaps it can be configured to handle this situation better than Apache can.
I had a problem years ago where I wanted customers using a client-server system with a proprietary binary protocol to be able to access our servers on port 80 because they were continuously having problems with firewalls on the custom port that the system used. What I needed was a proxy that would live on port 80 and direct the traffic to either Apache or the app server depending on the first few bytes of what came across from the client. I looked for a solution and found nothing that fit. I considered writing an Apache module, a plugin for DeleGate, etc., but eventually rolled by own custom content-sensing proxy service. That, I think, is the worst-case scenario for what you're trying to do.
To answer the specific question about mod-proxy: yes, you can setup mod_proxy to serve content that is generated by a server (or service) that is not public facing (i.e. which is only available via an internal address or localhost).
I've done this in a production environment and it works very, very well. Apache forwarding some requests to Tomcat via AJP workers, and others to a GIS application server via mod proxy. As others have pointed out, cross-site security may stop you working on a sub-domain, but there is no reason why you can't proxy requests to mydomain.com/application
To talk about your specific problem - I think really you are getting bogged down in looking at the problem as "long lived requests" - i.e. assuming that when you make one of these requests that's it, the whole process needs to stop. It seems as though your are trying to solve an issue with application architecture via changes to system architecture. In-fact what you need to do is treat these background requests exactly as such; and multi-thread it:
Client makes the request to the remote service "perform task X with data A, B and C"
Your service receives the request: it passes it onto a scheduler which issues a unique ticket / token for the request. The service then returns this token to the client "thanks, your task is in a queue running under token Z"
The client then hangs onto this token, shows a "loading/please wait" box, and sets up a timer that fires say, for arguments, every second
When the timer fires, the client makes another request to the remote service "have you got the results for my task, it's token Z"
You background service can then check with your scheduler, and will likely return an empty document "no, not done yet" or the results
When the client gets the results back, it can simply clear the timer and display them.
So long as you're reasonably comfortable with threading (which you must be if you've indicated you're looking at writing your own HTTP server, this shouldn't be too complex - on top of the http listener part:
Scheduler object - singleton object, really that just wraps a "First in, First Out" stack. New tasks go onto the end of the stack, jobs can be pulled off from the beginning: just make sure that the code to issue a job is thread safe (less you get two works pulling the same job from the stack).
Worker threads can be quite simple - get access to the scheduler, ask for the next job: if there is one then do the work send the results, otherwise just sleep for a period, start over.
This way, you're never going to be blocking Apache for longer than needs be, as all you are doing is issues requests for "do x" or "give me results for x". You'll probably want to build some safety features in at a few points - such as handling tasks that fail, and making sure there is a time-out on the client side so it doesn't wait indefinitely.
For number 2: you can get around crossdomain restrictions by using JSONP.
Two Three alternatives:
Use nginx. This means you run 3 servers: nginx, Apache, and your own server.
Run your server on its own port.
Use Apache mod_proxy_http (as your own suggestion).
I've confirmed mod_proxy_http (Apache 2.2.16) works proxying a Comet application (powered by Atmosphere 0.7.1) running in GlassFish 3.1.1.
My test app with full source is here: https://github.com/ceefour/jsfajaxpush