sorry if this question sounds kinda weird, but I haven't managed to get a satisfying answer yet.
The thing is, I am making( or willing to make ) a web-browser based game where people have their own company, trade, build etc.. And the game will also include bots. Because there will be quite a lot happening, it would be good for the bots to run at all times and react to various situations.
But.. I don't know how to make it happen server-side. Is there a way to make a script run on a server (like VPS)? Or is there a way to make some kind of application that would run on the server and communicate with the database and send answers?
Thank you :)
Of course there is a way to do this server-side - you "just" have to create a server, using any language/framework/platform that enables you to create a proper server application (this could be C++, Java, you could even stay in the JavaScript realm by using Node.js).
You would have to provide some kind of communication channel between web clients and your server. For that, you could use either Websockets (TCP) or WebRTC (UDP), simple AJAX could be an option too, but I wouldn't recommend it for persistent communication channel.
Related
I am developing a webgl application. I am confused in choosing the right server-side technology to use for the application. I an using mongoDB as my database and three.js as my webgl library to ease the development.
There are a lot of things to take into consideration.
first of all, what kind of connection do you need?
There are 3 ways of getting data from a server. Polling, long-polling, and a bidirectional connection.
Polling is the simplest. It's simply sending an AJAX call to a php or asp server, and the server replies.
Long polling is a little more complex. It's sending a request to the server, and the server decides when to answer this call. This can also be done using a simple php/asp script.
A bidirectional connection is when things really become complicated and you need to use websockets. As far as i know neither php or asp support websockets so node.js, for me, is the only option here. Its setting up a connection between client and server so you can pass data back and forth. It doesnt rely on the client requesting data, the server can also decide to sent data to the client, which in turn can make something happen.
As for the databases, i also found mongoDB to work great with node.js, i tried it and havent even looked at SQL since then because quite frankly, i absolutely dispise SQL. So its just a matter of what your personal preference is.
And finally the webGL framework. It also depends on what you want and how complicated you want to make it. If you also need physics and/or collision detection (while three.js does have a small collision detection system) i'd take a look at babylon.js as well.
I am using Flask and I want to show the user how many visits that he has on his website in realtime.
Currently, I think a way is to, create an infinite loop which has some delay after every iteration and which makes an ajax request getting the current number of visits.
I have also heard about node.js however I think that running another process might make the computer that its running on slower (i'm assuming) ?
How can I achieve the realtime updates on my site? Is there a way to do this with Flask?
Thank you in advance!
Well, there are many possibilites:
1) Polling - this is exactly what you've described. Infinite loop which makes an AJAX request every now and then. Easy to implement, can be easily done with Flask however quite inefficient - eats lots of resources and scales horribly - making it a really bad choice (avoid it at all costs). You will either kill your machine with it or the notification period (polling interval) will have to be so big that it will be a horrible user experience.
2) Long polling - a technique where a client makes an AJAX request but the server responds to that request only when a notification is available. After receiving the notification the client immediately makes a new request. You will require a custom web server for this - I doubt it can be done with Flask. A lot better then polling (many real websites use it) but could've been more efficient. That's why we have now:
3) WebSockets - truely bidirectional communication. Each client maintains an open TCP connection with the server and can react to incoming data. But again: requires a custom server plus only the most modern browsers support it.
4) Other stuff like Flash or Silverlight or other HTTP tricks (chunked encoding): pretty much the same as no 3). Though more difficult to maintain.
So as you can see if you want something more elegant (and efficient) than polling it requires some serious preparation.
As for processes: you should not worry about that. It's not about how many processes you use but how heavy they are. 1 badly written process can easily kill your machine while 100 well written will work smoothly. So make sure it is written in such a way that it won't freeze your machine (and I assure you that it can be done up to some point defined by number of simultaneous users).
As for language: it doesn't matter whether this is Node.js or any other language (like Python). Pick the one you are feeling better with. However I am aware that there's a strong tendency to use Node.js for such projects and thus there might be more proper libraries out there in the internets. Or maybe not. Python has for example Twisted and/or Tornado specially for that (and probably much much more).
Websocket is an event-driven protocol, which means you can actually use it for truly real-time communication.
Kenneth Reitz wrote an extension named Flask-Sockets that is excellent for websockets:
Article: introducing-flask-sockets
Github: flask-sockets
In my opinion, the best option for achieving real time data streaming to a frontend UI is to use a messaging service like pubnub. They have libraries for any language you are going to want to be using. Basically, your user interfaces subscribe to a data channel. Things which create data then publish to that channel, and all subscribers receive the publish very quickly. It is also extremely simple to implement.
You can use PubNub and specifically PubNub presence meant especially for online presence detection. It provides key features like
Track online and offline status of users and devices in realtime
Occupancy to monitor user and machine presence in realtime
Join/Leave Notification for immediate updates of all client connections
Global Scale with synchronized servers across the PubNub Data Stream Network
PubNub Presence Tutorial provides code that can be downloaded to get presence up and running in a few minutes. Five Ways You Can Use PubNub Presence shows you the different ways you can use PubNub presence.
You can get started by signing up for PubNub and getting your API keys.
The company I'm working at uses Perl for all "backend related" stuff. However, we would like to use some real-time communication between server-processes and connected clients via browser.
We are also using Apache as Webserver with mod.perl. So that is my first question, I don't see any practical way to combine a WebSocket-Server in that constelation. Maybe there is one I didn't found yet?
The only thing which really works serious about that topic, is Mojolicious. However I'm not that experienced with that yet, so I'd be happy if someone could state if I can use that in my current mod-perl environment. I think I also would have to let this run as standalone webserver process, No?
Which brings me to my second question. What is the best practice, if you have multiple perl files, which do certain things running on Apache/modperl, but you want to keep all your connected users informed about things. What I mean is, all these scripts are accessed via XHR, but some actions require other users to get informed. Currently, we do a classic ajax polling.
The problem I'm struggling around with is, that if there is a dedicated websocket server, which runs independently, all those scripts would need to somehow communicate with this process as well right ? How would one do that? Pipes? Sockets? Shared memory ?
Theoretically, if I would choose to go with such an independent ws server solution, I could write it in any language right? Could even be Ruby or Node. I'm just wondering if that is the best way or if there is a good solution which is more integrated in existing perl/modperl constructs.
TL;DR
Is it best practice to have a standalone, independent web-socket server which communicates with the rest of your Apache/modperl scripts aswell as with its connected clients ?
You could look on AnyEvent CPAN module:
http://metacpan.org/pod/AnyEvent
With it you can write your own standalone event-driven WebSocket-server, also you could find a lot of examples in google or in AnyEvent's perldoc.
I wanted to be allow users to play p2p in a multiplayer game that I'm developing, but to be able to do that, javascript needs to be able to create a socket server in the browser. Is that even possible? I don't know of any API that let clients connect to other clients in javascript. Is there any other way? Like using a hidden flash element?
I am asking for something that doesn't require a server at all. The packets need to travel from client to client directly
In short no, p2p in a browser is not possible.
The closest you can get is using NodeJS (for potentially p2p JS) or a centralised server (or several servers) and websockets (for sockets in a browser)
This question is old, but I can now give an answer: YES, there is finally a way to do p2p communication between browsers!
Thanks to the new standard WebRTC, modern browsers got support for Data Channels, something much more powerful than WebSockets.
Take a look here:
WebRTC Data Channels
Online Example: Banana Bread 3D is a First Person Shooter game compiled to JS+WebGL, using WebRTC data channels in multiplayer mode:
BananaBread 3D Multiplayer online fps game
Interesting question, but probably a duplicate:
What techniques are available to do P2P in the browser?
i know for sure this can not be done using only javascript(in every browser). According to another answer on Stackoverflow in above topic you might be able do this using rtmfp-api.
This project expose Rtmfp protocol (provided by Flash version 10) to
javascript application throught a hidden flash applet. The protocol
allow multiple clients to communicate directly. See the references for
more details about the protocol.
Looking quickly at the site you still need a rtmfpUrl-server in the middle, which i totally understand because the clients need to be be able to find each other(IPs). But I assume after that it will be p2p. Doing a quick search I also found open-source rtmfp-server(s).
I haven't tried this out myself, but I maybe this will help you achieve your goal.
Some other links:
https://stackoverflow.com/search?q=browser+p2p
https://stackoverflow.com/a/7933140/11926
https://stackoverflow.com/a/5211895/11926
https://stackoverflow.com/a/5023048/11926
While this is a shopping question, i'd look into APE
http://www.ape-project.org/
At the very least you could check out how they've structured it.
In order to implement such a game, your JavaScript client must communicate with the server. The server then runs the game logic, and sends the result back to the client.
JavaScript receives user input and sends it to the server
Server ensures that the input is valid (to prevent cheating) and updates the game with the new input
Server periodically sends the game state to JavaScript (either by long polling or by having JS request it at an interval).
Basically, never trust anything coming from JavaScript as it is extremely easy to modify. Everything should be done server-side.
Here's a solution with mobl (but I haven't tried it yet).
http://zef.me/3391/moving-the-server-to-the-browser
It is possible to go serverless with Flash. This is doable with Adobe Flash's Peer to Peer capabilities. I once wrote a peer to peer chat with it. The drawback is Actionscript is a dying language and may not be supported much in the future.
Here is the raw class.
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/NetGroup.html
Here is resources if you don't want to write your own.
http://www.as3gamegears.com/category/multiplayer/
If you want a Server option that is light on the server side. Try this node.js extension.
http://socket.io/
I recommend using a java socket server of some sort. Electroserver used to be one of the leaders in the field, it had Unity support and was scalable to hundreds of thousands. Although I think they have fallen on hard times. The Electroserver site has not been accessible for sometime. I know there are others out there but Electroserver is the only one I have used.
I'm building a web app for 'brainstorming.' Here's how it works: essentially, a user can come onto the app, and submit a challenge, or click on one that's already there, then think up ideas to resolve that challenge and post them up. I hacked together a basic example here on couchdb: http://wamoyo.iriscouch.com/ideageneration/_design/IdeaGeneration/attachments%2findex.html
I'm going to rebuild it from scratch and all, and I'm hitting up against a challenge that's very unfamiliar to me. I'd like for multiple users to be able to generate ideas for the same challenge at the same time. Kinda like the way google docs allows multiple people to edit a shared document. I have some preliminary thoughts on how to go about this, but I thought I'd ask the expert network here.
I'm fairly comfortable with AJAX, is there a pure AJAX way to make it live and multiuser? Would there be an enormous benefit to going with node.js? What might be some other options?
Thanks soo much!
There are several approaches in making such web pages, using plain ajax polling, using long polling and using web sockets.
Ajax polling - easy to implement, essentially connecting to server recurrently via javascript timer, retrieve data from server and send it back via regular Ajax.
Advantages: easy to implement, works everywhere
Disadvantages: the updates are not in real-time, the data is exchanged only when the timer ticks.
Long polling - the idea is that the connection stays open until it times out, then the connection is reestablished. Can be tricky to implement because of different settings for request timeouts for different web servers, routers, etc.
Web sockets - part of HTML5 umbrella, works only in fairly modern browsers, the protocol changes often which may cause incompatibilities during development and production. Can be used natively with modern browsers and via a Flash plugin with older ones. This technology is most lightweight, because it doesn't incur all the HTTP overhead. Think of it as bi-directional, full-duplex communication channel between a browser and a web server via TCP.
For a detailed discussion, I recommend reading this good post by Scott Hanselman. It tells the story about SignalR, but is applicable to other server-side frameworks.
There is also a podcast by same author, the guest goes fairly deeply into explaining these technologies. Worth listening, IMO.
To answer your question about node.js, please share us your current server technology, so we could get more insight into your stack.