I am creating an online game.
My game will dynamically create servers (websockets) using hourly server hosting, and the amount of servers / lobbies will expand / shrink depending on the number of players online. It is not very feasible to have pre-created servers constantly running. I then have an IP address for each server.
The problem comes when I want to connect to the game IP from my website. I can't connect unless I disable CORS protection and also disable HTTPS on my website. I could do this to begin with but isn't great in the longterm for security reasons and because the browser shows that a page is insecure if it is in HTTP.
The other option is to create a subdomain on my domain for each game server IP and setup HTTPS. The problem with this is that the DNS could take hours to update, which is a problem because I am dynamically creating and destroying servers.
The final option is to create a single server proxy (could be spread across multiple nodes using load balancing) that forward messages from the client to the actual individual game servers. The problem with this is there will be a lot of extra latency, obviously being a problem for games.
How can I achieve a secure IP websocket connection in the browser, or is there a better compromise than what I've come up with? With webassembly and browser openGL on the way I would expect that something like this was thought through and there is some solution.
Related
I'm trying to build a website that allows you to transfer files to devices connected on your local network. This website is static, and will be hosted on GitHub pages.
Is it possible to use Javascript to communicate with (i.e. transfer files/text) other devices on the local network? The IP addresses of the devices are already known and I'm looking for a peer-to-peer connection here.
Note: As this website is static, there is no server side code that can be controlled.
Thanks
Yes, it's possible with caveats, depending on the specifics of your situation.
WebRTC
With WebRTC, you can establish a real peer-to-peer connection between two clients on a network. They can send data (binary or strings), and media streams (like webcams and microphones). This can even work from a static page.
The catch is that you need some sort of server to help coordinate the connection. Because of the way the WebRTC standard was originally set up, there is some back-and-forth that must occur to set up that peer-to-peer connection. Some method of communicating the signalling between the clients must exist, and this is usually done via web sockets and an intermediary server.
There are some novel alternatives.
In the future, ORTC may solve this issue, allowing a one-shot method for setting up the call, making the server-side requirements easier.
Embedded HTTP Server
You didn't elaborate on the specifics of what device you want to communicate with on your network, so maybe this is a possibility as well. There's nothing stopping your browser from communicating with devices on your LAN. Your static web page can use the Fetch API or AJAX to retrieve data from devices.
I have a logic written on my server mostly doing curl requests (e.g. accessing social networks). though, some of the sites, will be blocking my server(s) IPs soon.
I can of course, use VPN or deploy multiple servers per location, but it won't get accurate, and still some of the networks might get block the user account.
I am trying to find creative solution to run it from the user browser (it is ok to ask for his permission, as it is an action he is explicitly trying to execute) Though I am trying to avoid extra installations (e.g. downloadable plugins\extension or a desktop app)
Is there a way to turn the client browser into a server-proxy, to run those curl-calls from his machine instead of sending it from my own server? (e.g. using web-sockets, polling, etc.)
It depends on exactly what sort of curl requests you are making. In theory, you could simulate these using an XMLHttpRequest. However, for security reasons these are generally not allowed to access resources hosted on a different site. (Imagine the sort of issues it could cause for instance if visiting any website could cause your browser to start making requests to Facebook to send messages on your behalf.) Basically it will depend on the Cross-origin request policy of the social networks that you are querying. If the requests being sent are intended to be publicly available without authentication then it is possible that your system will work, otherwise it will probably be blocked.
I'm new to Web Sockets in general, but get the main concept.
I am trying to build a simple multiplayer game and would like to have a server selection where I can run sockets on multiple IPs and it will connect the client through that, to mitigate connections in order to improve performance, this is hypothetical in the case of there being thousands of players at once, but would like some insight into how this would work and if there are any resources I can use to integrate this before hand, in order to prevent extra work at a later date. Is this at all possible, as I understand it Node.Js runs on a server and uses the Socket.io dependencies to create sockets within that, so I can't think of a possible solution to route it through another server unless I had multiple sites running it separately.
The first question I have is this:
Are you hosting on AWS or in a local datacenter?
The reason I ask is because SOCKET.io requires sticky sessions to work properly across multiple servers. Due to the fact that SOCKET.io will attempt to upgrade each connection, and because that upgrade request must reach the original server that authorized the session, you'll need to route websocket (TCP) connections back to that original server via sticky sessions. Unfortunately AWS makes this extremely tricky and will require you to learn how to:
A) Modify elastic load balancer policies to forward protocol information
B) Split apart TCP connections from standard web requests using something like HA PROXY or NGINX. This is necessary in order to handle web socket UPGRADE requests properly, as you will be setting TCP to sticky and web requests to round-robin.
C) Attach your socket.io configuration to a common storage source, like Redis (elasticache).
Once you've figured out what's needed for AWS (or if you've got full control over request routing at your local datacenter), you'll want to architect your SOCKET application to use multicast rooms rather than direct socket messaging.
Example:
To send a message to users in game #4444, emit a message to room 'games:4444', rather than direct to the user's socket.
If your socket instance is configured using REDIS, REDIS will automatically take care of maintaining lists of people who are connected to your 'games:4444' channel. Otherwise you'll need to maintain the list yourself using a database or other shared mechanism.
Other than that, there are plenty of resources online that can help you figure out each step along the way. I'd start with understanding something like HA PROXY and how it can help split apart your SOCKETS from your web requests.
TL;DR
In Javascript, how do you to find the IP of all servers running a specified program on a specified port in the LAN?
Background
I'm writing a server in node.js that is supposed to connect users browsers as controllers to a common device on which a game is running. The browsers are running a web app based on html and Javascript. The connection is based on socket.io.
I'd like for the web app to be able to find all available instances of this server in the LAN in order to create a server list for the user to choose from.
Is there a way to make the server discoverable by the web app on the local network in Javascript, and in that case: how?
Ideas
Have the server broadcast its IP to all devices on the LAN and have the web app listen for these messages (No idea how to do this without node on the client)
Connect to every IP on the network and see if the connection is successful. (Does not seem feasible)
Scan every IP on the network and connect only to those where the port is open. (Once again, no idea how to do this without node on the client and does not seeem feasible either.)
EDIT
The server is supposed to be portable and work independently, without any central system backing it up or providing matchmaking for clients. It is a LAN only server and should work even without internet access.
There is no way for you do this. Sorry. Since there is no exposure to UDP on client-side JavaScript, broadcasting is out of question. Any attempt on massive scanning will quickly raise flags on network monitoring software. You have to use a known address.
I want to limit the limit users who connect to my live streaming page, such that users can't share passwords and login multiple times under the same account, from different locations.
I don't mind if one user logs in on two different devices at his home, like a computer and a Google TV, for example. This makes me think restricting based on source IP address is the right way to handle this.
The problem is that if the user logs in, and I record their IP address, and restrict them to logging in just from that IP, they can't change locations.
With HTTP, after they log in, it's connectionless, so I've lost track of if they are watching the stream from the CDN or not.
It makes me think I should use javascript on the client to disconnect the player if the user logins into another location.
This means I need to have a way to communicate to logged in clients in a reasonably scalable way.
Can you suggest an appropriate way to handle this problem? I have the feeling there must be a simple and scalable solution for this.
It really depends on how sensitive you are to people bypassing your access controls.
If you're ok with some people bypassing them, then you can perform access control on the client side and have the client ping the server every 60 seconds or so telling the server that it's still streaming. Then in the server, store the IP address of the user in an expiring queue. So the IP address would expire out of the queue in, say, 3 minutes if the player stops pinging the server. And by pinging the server, I mean sending a simple http GET request to keep the session open. When the user closes the client, the pings would stop and your server would expire the IP address for that client after 3 minutes. At that point the user could log in with a different IP address.
It's important to keep in mind that savvy users would be able to watch the networking events in a browser like Chrome and see where your content is being served from and easily bypass any restrictions because you have no control over the CDN itself.
If you need stricter control, you'll need to serve the content from your server. Then you'll absolutely know when a client has stopped accessing a stream.
There might be a middle ground. If you're worried about streaming speed without a CDN, you might consider taking a look at CloudFlare.com. CloudFlare is a CDN layer that sits in front of all of your http requests, even the dynamic ones. The static requests are served from the edge, like a normal CDN, but the dynamic requests are reverse proxied through CloudFlare's network, back to your server each time. If you setup your streaming requests to look like dynamic content to CloudFlare then the you would gain the potential benefit of streaming over a low latency, high bandwidth connection to the edge point while still being able to track users individually.