As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm planning to build a small multiplayer game which could be run as a java applet or a flash file in the web browser. I haven't done any server programming before, so I'm wondering what sort of server architecture i should have.
It'll be easy for me to create perl/php files on the server, which the java/flash code contacts to update the player position/actions, etc. But I'm considering whether i should get a dedicated web host, which OS to use, which database, etc. Also, the amount of bandwidth used and scalability is a consideration.
Another option could be using a cloud hosting system (as opposed to a dedicated server), so they would take care of adding additional machines as the game grows. As long as each server ran the core perl/php files for updating the database, it should work fine.
Yet another option could be using Google app engine.
Any thoughts regarding the server architecture, OS/database choice, and whether my method of using perl/php/python scripts for server-side programing is a good one, will be appreciated!
You need to clarify more about the game, and think more about architecture rather than specific implementation details.
The main question is whether your game is going to be in real time, turn based, or long-delay based (e.g., email chess). Another question is whether or not you are going to be freezing the state for subsequent reloads.
I would highly recommend figuring out in advance whether or not all players in the same game are going to be hosted on the same server (e.g., 1000 of 4 player matches compared to 4 matches of 1000 players each). If possible, go with the first and stick everyone who is in the same game under the same server. You will have a hard enough time synchronizing multiple clients to one server, rather than having multiple servers against which players are synchronized. Otherwise, the definition of consistency is problematic.
If possible, have each client communicate with the server and then the server distributing updates to the clients. This way you have one "official state", and can do a variety of conflict resolutions, phantoms, etc. Peer to peer gives better performance in faster games (e.g., FPSs) but introduces tons of problems.
I cannot for the life of me see any convincing reason to do this and perl or PHP. Your game is not web based, why write it in a web oriented language? Use good old J2EE for the server, and exchange data with your clients via XML and AJAX. If possible, run a real Java application on clients rather than servlets. You can then benefit from using JMS which will take a huge load off your back by abstracting a lot of the communication details for you.
For your server architecture, you might have a look at Three Rings' code. They have written a number of very scalable games in Java (both client- and server-side).
I would also discourage from using PHP, also HTTP isnt the best idea as it is stateless and talkative. I was working for some time in company currently developing really massive multiplayer game. The back-end is plain JVM (being connected thru tomcat by multiple clients and from mobiles one per client). So I know the less data you transfer the smaller buffers you need on server -> more clients on one machine and also a bit faster responses. Also consider security, https is quite expensive, especially if you need to transfer graphics and sounds. Binnary protocol of your own with non-browser client container would do the best (good choice is switchable protocol for the development-debugging time). Maybe sounds complicated but it isn't.
#Sarah nice hint, thanks too ;)
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I need some help on how to choose a technology for developing mobile apps. I have decided to use phonegap (cordova library) and Jquery mobile with HTML and complete my device APIs and UI parts.
Now I am in a dilemma, on which technology to use to connect to a database -
1. PHP
2. .NET
3. JAVA
I heard/read PHP is light-weight and is easy to work with but .NET is more robust and secured. Now, I am unsure of what exactly security here means? Does it mean PHP is not a secured way to handle database operations?
Can anyone please guide me on how to decide on a technology and take my development to a higher level?
I can give you more inputs as required. :)
Many thanks.
If you never ever touched any of these technologies you should use the easiest one.
Your priority should be like this, I will rank then from according to their usability/simplicity:
1. PHP
Good:
By far simpliest of them all. In a matter of days you can learn more then enough to create your basic server. No matter do you want to handle only REST calls or do full a page creation on a server side.
It has largest overall support and you will easily find hosting, if you already don't have it. It works on all current desktop OS's like Windows, Linux and MacOS.
Bad:
Not that much. If I have to think of any I would say that it is a smaller brother of Java and .NET.
2. .NET
Good
My favorite, more secure (but not that much secure) then PHP. It requires much more time to handle and use right. Like with Java I prefer its syntax over PHP. Still more readable syntax then Java, specially if you delve into something more complex.
Bad:
But, as it is a Microsoft technology it will run only on a Windows platform. Skipp it if this is a turn off for you.
3. Java
Good:
Almost best of both worlds. Better and more powerful syntax then PHP and unlike .NET you can run it on any available platform. Like .NET it requires more time to master correctly then PHP.
Bad:
Java is usually used in large corporate projects and you will not find that much help over some basic stuff and usage. Even if you master it correctly you will still need to delve into Java EE if you want to create anything decent and robust, basically it is a largest time sink if you only need to create one server application. Other problem is memory consumption, that is why you will see much less available Java hosting platforms the it is case with .NET and PHP.
Conclusion
If you don't have that much time and you are not sure you are ever going to use it again then stick to PHP. If you are planing on using this technology for a longer period then stick to .NET. And finally if you are going to use it in a longer period but Windows platform is a turn off then stick to Java.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
As a Java developer I'm going to participate in a web project. So I'm trying to get informed on different aspects of web security.
Now I have came to the DoS attack subject and I'm trying to figure it out what I can/should do as a Java developer. Or may be it would be the system administrator job.
What comes to my mind at first is to implement the functionalities in a way so a single request can not take too much time and resources. For example to put some limits on the amount of the processed data. But I'm not sure if this will be applicable in all cases.
Should I take any care for DoS due to many requests?
Any advices will be appreciated.
Many thanks in advance!
Firstly, there's nothing either of you can do to prevent a DoS attack.
All you can do is make your code sensible (Developer), and your architecture robust (SysAdmin). It is a joint effort.
Developers should try to minimise resource usage as part of their job anyway - not just for DoS attacks.
Developers should use caches to protect the database. If every request needs to consult a list of Countries, then requesting that list from database every single time isn't good practice anyway.
Developers should make sure that bad requests fail as quickly as possible. eg. don't consult the Countries list at all, until you've verified their account number actually exists.
Developers should adopt approaches like REST: treating each request individually rather than maintaining Sessions in memory. This could stop your memory usage from rocketing during an attack. You don't want memory problems as well as your network being flooded!
Developers should make their application scalable. Again, REST helps here as you aren't tied to having things stored in memory. If you can run ten instances of your application at once, each handling a subset of the requests, you will last much longer in a DoS attack (and probably give your users a smoother website experience anyway).
SysAdmins should provide the load-balancing, fail-over, etc. frameworks to manage this scalability. They will also manage hardware for the instances. You could also have the option to add more instances automatically on demand, meaning that automatic server creation and deployment become important. Using VMs rather than physical boxes can help with this.
SysAdmins can set up firewalls and proxies so that, when an attack does happen, they can keep your REAL traffic coming through and stop the attack traffic. They can filter traffic by suspected IP range, block 'suspicious-looking' requests, throttle traffic levels to a gentle flow, etc.
Overall, you can look at DoS as just "high amounts of traffic". If your application code and architecture can't cope with increasing traffic from "regular users" then you are doomed anyway, regardless of a DoS attack. When Facebook was threatened with DoS, I remember someone pointing out that "Everyday is a DDoS attack for Facebook...". But it is developed and structured in such a way that it copes.
DoS attacks are usually the concern of IT. If you are developing a web application, usually it's behind a front controller (apache, nginx, etc) that forwards requests to your application container (Tomcat, Rails, etc... ). The front controllers usually/always have logic to deal with this issue
If you are an application developer, then concentrate on XSS attacks (http://en.wikipedia.org/wiki/Cross-site_scripting) as that is totally within the application developer's responsabilities
I'd say that it is the sysadmins concern mainly, but that doesn't mean that the developer shouldn't take measures to avoid it.
Since DoS attack usually is about bogging your system down with requests so that it cannot handle real requests (Denial of Service), wikipedia has this to say about DoS prevention:
Defending against Denial of Service attacks typically involves the use of a combination of attack detection, traffic classification and response tools, aiming to block traffic that they identify as illegitimate and allow traffic that they identify as legitimate.
In my opinion these are sysadmin tasks, since they are the ones who should be configuring the firewall, routers, switches etc.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I want to develop an application where server pushes a lot of data to client. (20 kb every 20 milliseconds) 500kbps. All of the data are double/float values.
I am trying to answer the question, if there is something inherent to desktop apps (Java Swing app) which will make it a better option for this use case as compared to a web app where data will be pushed over http.
Is there something about Java swing app and how data transfer takes place there from server to client, that makes them faster as compared to web apps (tomcat as app server .. JS at client side).
And how answer varies, if I say that web server and application are on the same local network.
My vote is desktop, but I'm bias (when the only tool you have is a hammer...)
My first thought is threads and custom networking. You get the added benefit of push and pull protocols as you need (yeah you can get this in a web environment to, but Java was designed for this, AJAX has been bent this need)
I'd also push a diverse and customisable UI toolkit, but one might argue that you can achieve this using HTML, but I've, personally, found the Swing toolkit faster to get running & easier to maintain, IMHO.
The downside would have to the need to install the app on each client machine and deal with updating
That's my general opinion anyway, hope it helps
The other question is, what does the app need to do?
It is highly unlikely that the UI will be displaying 1000 meters all at once. The users will most likely be looking at small number of meters at a time. The UI only needs to be updated for the meters that are displayed on the screen. This should cut down on the load considerably. Assuming that networking and cache database components will be about the same for both web as well as desktop app, the real differentiator then becomes how fast the charts/graphs can be rendered, and how often or how many people will be inclined to use it.
MadProgrammer's suggestion of prototyping make sense. The test data gained from the prototypes would answer the performance question.
Web based will be more useful/valuable because it can be used from any desktop, tablet or smartphone. I am assuming that it is desirable to get the data in front of as many users as possible, anytime and anywhere. Also, I don't think human eye can detect 20ms updates. You could probably make that longer and users would not even notice it. Movies are about 25 frames a second, i.e. 40ms/frame.
How many concurrent user are you anticipating? I don't think that should affect the solution as both can be made scalable.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I've been programming for a while now, and I am pretty familiar with Java and PHP and websites. What I'm confused about is how programmers use them together. I hear about how Facebook and Google use all sorts of languages like Python, C, Java, PHP all for one product, but I'm just confused on how that would be possible.
Also, another side question:
What work exactly do software engineers do when working for large online companies like Twitter and Facebook? Most of the code deals with database and information, and so what major level programming, besides what can be learned online with a few tutorials, needs to be done on the server side?
This is an incredibly broad question, but here's a shot at a vague answer. Often times large applications will have a number of components. For instance, you may have some sort of reporting engine, business logic, web interface, desktop interface, web service API, mobile interface, etc, etc, etc. Each of these could, in theory be written in a different language and communicate via a database or something like a web service.
To your second question. At large companies there is a great deal of work to be done to maintain stability, develop new features, fix bugs as they are discovered and work to increase efficiency etc. Facebook, for instance (and Google) employs a large number of software engineers to help them deal with the massive amounts of volume they receive on a daily basis.
Edit Here's a bit more clarification and a direct answer to your question.
Most of the code deals with database and information, and so what major level programming, besides what can be learned online with a few tutorials, needs to be done on the server side?
The truth is, for the most part, the high-level principals are the same. You could pretty easily build a Facebook clone after doing some basic PHP/MySQL tutorials on the web. Here's the difference: your clone would die before it reached a fraction of the users Facebook sees on a daily basis. It would be slow, unreliable and people would leave because their data would be consistently hacked through SQL injection and other malicious attacks. And that's not even talking about distributed computing. So, yes, from a high-level, that's all you need to know. The implementation and reality is much, much more complex.
As you might expect, larger "websites" are not built in the traditional sense that you have some PHP code, a few HTML templates and a database, since this kind of architecture has severe issues scaling to thousands of concurrent users.
What you can to to mitigate this is split the website out in several components:
Load balancers that distribute requests to several App servers
App servers which generate the UI and handle user actions
Middleware servers that handle business logic and distribute it among DB servers
DB servers that store data in some way
Every component of this system might be implemented in a different language and you might even have different app servers depending on request type (e.g. mobile devices).
This type of system is called Multitier Architectures. You can also find academic books on this topic.
Most complex products consist of numerous pieces. For example, StackExchange has code that runs in your browser that's written in JavaScript so it can run in your browser. But the code that builds the web pages doesn't run in a browser and so isn't written in JavaScript. And if complex database queries are needed, they're likely to be in SQL. And so in. Each piece of the big puzzle is implement in the language most appropriate for what that piece does and the environment in which it runs.
Thank about GMail. There's a in-browser piece that's written in JavaScript. There's also a web server, a database, a mail server, a bulk storage system, indexing, and many, many other pieces.
this is the actual answer you are looking for
you are confused because you dont see how using the C and C++ applications in websites but I want to tell you that, they are used for many things... like, when you upload a image in facebook containing pornographic content, then php wont validate that image, what they will do is that execute a program by passing the address of that image by parameters and that application will validate the image... and some data should be stored for future use, so that application uses the common database that the site is using, if we upload a image in googleplus, then it will load tag sugestion to some part where people's faces are seen, it is done by that app, it will save the image data to the common database which google is using and php takes that information from there, this is the technique of developing much more functional websites...
like, i have made a program to shutdown my home computer while working on localhost:
<?php
$command="shutdown -s -f -t 5";
shell_exec($command);
?>
this script once run in apache will shut the server down similarly you can pass the parameters into some apps like if you want to create email account in command line for your own server which dont have Cpanel installed...
and the answer of second part of your question:
actually software engineers are hired so that they will develop some apps that can be run in a server for increasing the functionality of the website... like if there would be only webscripting language for websites, then google couldnot recognise the face neither facebook, and artificial intillegence would not be possible for websites..
this post may clear your confusion...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
So I apologize if I'm posting this in the wrong place but I thought asking the coding crowd would be best.
So I'm building a website with 3 developers. One dev is on front-end, one on PHP back-end and one on the database design. The core application of the website is actually much more complicated than i/we (the devs here) originally imagined it would be. The hardest part is in the database design and the design and development of the CMS to manage the database. Working closely with one dev, we have created the final version of the database. This is good news. Meanwhile, the rest of the site is being built with Zend with the other 2 developers.
Essentially what has happened is that the database designer that I have been working with has all the knowledge in his head because he worked with me consistently to design the DB by learning about the technicalities of the domain, industry terminology, the system requirements and so forth. He has also designed the CMS to manage the products that we will insert as per his data structure. Logically, he should really be the one then to code the core application because he knows deeply what he designed. However our system is in PHP and he's a Java dev. So I'm pondering what do to. He has agreed that he could learn PHP in about 2-3 weeks he estimated but admits that at the start, coding would be quite slow while he falls over a few times.
The lead developer on the other hand knows little about the requirements of the core app, the design of the database, the products and the business domain and would therefore take a long time to go through the same process of transferring all this knowledge until he's intimately familiar with everything. So its really a question of time. Would it be faster for a 6 year Java dev to learn PHP and build the core app or would it be faster for the 6 year PHP dev to pick up the knowledge from myself and the database dev?
Is it a close call? Is there a clear winner?
Any advice/suggestions?
Thanks
In essence I think that having experience of design and a good knowledge of how systems work is the most important thing.
Individual languages can be learned (and yes, there is a learning curve, while the syntax is absorbed, then the idioms, etc) and whilst having someone who knows a language when they start makes them a little quicker off the mark, I would choose someone with good design skills over someone with weaker design, but more knowledge of the language.
Language skills can be learned much more quickly than design principles.
In your situation, you have a problem. Two good people with different skillsets. Surely the ideal solution (if it's financially viable) is to have them work as team. Then both will learn much more quickly from the other where they are weak - and they'll be able to discuss design issues and rational. You should end up with a vastly superior product, and two developers whith enhanced skillsets and expanded experience. A win-win, if they can work well togther.
I agree with #Ragster - get the database guy and the UI guy to work together. There's even a buzzword for this - it is called pair programming.
But I'd add one thing. It sounds like a significant part of the problem is that the database guy has all of the knowledge in his head ... and there is nothing written down. This is not good. What happens if the database guy is run over by a green bus?
Maybe you need to make the database guy's number one priority to document the database design in a form that the UI guy can assimilate.
I would vote for using the experienced PHP dev rather than one new to PHP. Any experienced PHP dev should be able to take a brief from you and your colleague on what is needed and utilise the db design work already done.
A dev new to PHP will not produce code that is as well written as an experienced dev and that could cause you problems in the future.
The other solution would be to use Java for this application even if some of your other apps are PHP based. The two can live pretty well side by side.
I'd vote for the PHP-dev, working alongside the database/java dev.
That way, the database/java dev begins to get exposure to PHP, which will help his learning curve; while the PHP-dev will pick up the database structure and the all-important business rationale/details from the database/java dev.
You shouldn't create a dependency on any one person if you can help it, but distribute the application knowledge across your team. This way, you'll end up with a stronger team overall.
You should also ensure that the knowledge isn't maintained purely in anybodys head, but is documented. Always consider the dangers of a number 17 bus when all the knowledge is in somebody's head.
The nature of your question implies that you expect your programmers to develop in single-user mode throughout. I have honestly never met a situation where that was less appropriate than for you right now. Allow/instruct the obvious candidates to use pair programming, and the problem will simply dissolve into thin air. You will get better understanding within the team, faster results, better code, more unified solutions all around...
I am not being flippant here. If you have any historical or even ideological aversions to pair programming, please please please try to just get over them. It just is that much more efficient.