smartfoxserver.com

First of all, apology if this has been asked before, I couldn't find it from the search.

Which method would be better for building a virtual world that has a lot of database transactions as well as game communications:

A. Use SFS custom extensions to perform database operations, so all communications and database transactions are handled via socket
B. Use Flash remoting for database operations so it frees up SFS to handle heavy game communications

Thanks,
Copet80

I am not an expert, but how can you secure A, when the client is responsible for db operations.
Also from my exp sfs have no problems with db communications if you put insert/update queries into separate threads and optimize a bit selects..

Hi corwin, I thought A is the "common" way of doing things with SFS custom extensions. There's no 100% security, packet sniffing is always possible, and security is not my forte.

Yes, db communications using separate threads are good and I've seen a lot of people in the forum are doing it. However, what I'm interested to find out is whether using Flash Remoting to talk with the back-end server would actually be more optimal, since that means we're not relying on SFS custom extensions, thus freeing it up to handle mainly game communications (i.e. messaging, user variables, room variables, etc.)

Anyone have any opinion?

Regardless of performance, it's pretty much rule #1 in any client-server system (whether a game or a serious application):
NEVER LET THE CLIENT DIRECTLY SET DATA
If you make your DB accessible to the client, it's going to pretty easy for anyone malicious to figure out how to wipe or screw up your entire DB.

Thanks, jdx. I agree that we should never let the client directly set data. But when I'm talking about remoting, I was thinking about connecting to Java back-end as usual. The point that I'm trying to figure out is whether it's faster to replace the game-business logic from SFS to remoting. Please see the diagram below.

Or you can use clustering - i.e. multiple machines working together. So that one machine can handle all the SFS related stuff while the other machine can handle all database transactions.

See - http://www.smartfoxserver.com/clustering/

Hi BigFIsh, you're right, but we're not even onto that point yet. Let's say, we only have one server and within the server itself we can do whatever we want. And say your game has high-traffic on both game chats and micro-transactions (virtual currency only), would you use SFS custom extensions to handle those transactions, or would you move them out to Flash Remoting so as to free up the SFS server just for game chats?

would you use SFS custom extensions to handle those transactions

SFS is quite capable of handling lots of traffic. Have you seen the performance benchmarks (http://www.smartfoxserver.com/whitepape ... index.html and http://www.smartfoxserver.com/whitepape ... index.html)? Furthermore, SFS implements thread-safety --> http://www.smartfoxserver.com/docs/docP ... Safety.htm and you can create additional (separate) threads if you want to.

would you move them out to Flash Remoting so as to free up the SFS server just for game chats?

It's really a matter of security. If you are 100% sure that it's hack-proof, then go for it.

copet80 wrote:Thanks, jdx. I agree that we should never let the client directly set data. But when I'm talking about remoting, I was thinking about connecting to Java back-end as usual. The point that I'm trying to figure out is whether it's faster to replace the game-business logic from SFS to remoting. Please see the diagram below.

Aha, now I see what you mean, going a more traditional application route for the DB stuff.

Based on my experience I wouldn't worry about performance unless you actually have a ton of users? Plus it seems like it might be a bit tricky to orchestrate how your SFS part knows the state from the DB?

Have you checked the power supply of the server? Does it run on 240v or is it off any UPS? Make sure the network cables are plugged in as well.