epozdnyakoff

No, it's not. You could implement a text template-based POX or RESTful interface and a socket server implementing a subset of HTTP. The latter is less than fifty kilobytes of code when done right. And it's not overkill, but a handy feature that'll reduce database load when building web services such as maps or online users list - you could export those through it and not fall in the Database-As-IPC antipattern. Remember the Antrix's statistics page that was implemented as a server's module. Just relax, we're protected by the power of OpenSSL. No enemy can break through our encrypted channels, so why bother limiting our web services to localhost?

Since there's an acceptable way (your class, actually) to validate passwords from within an php script, usability isn't affected in any noticeable way. Moreover, due to SRP being an infrequently used protocol it would dramatically decrease common cracking methods' (such as rainbow tables) effectiveness. But then comes robustness. Do you have enough experience with php doing bigint math to trust it in generating authentication information? SRP is no bubble sort, so you may end up with users frustrated being unable to log in. So I am against it for now.

Sorry, my bad.My case was solved by manually removing references to tbb from vc9 solution file and using USE_STANDARD_MALLOC (Had to do both, TBB somehow couldn't be deleted by the IDE).

VC++ 9 express build is broken too (as of yesterday).

I second that. A lot of CPU cycles and bandwidth would be saved. The way queries are sent now is absurd - adding backslashes, compiling and sending queries that are a hundred bytes long.Ambal, I would also like to know your opinion on adding an ORM layer to mangos. We could add metadata to SQL tables, then parse it with a standalone utility and create a class with methods to load and save records to database. Then we can further optimize database accesses by applying caching, keeping least recently used records in memory. This will also allow caching the entire database in server's memory, thus reducing the overhead of IPC between the server and the database to zero.

It's all about tradeoff between generality and performance. ODBC was originally created with 'buy bigger hardware' scalability in mind, so we'll lose ability to fine-tune settings such as locking policy in SQLite. And there are performance issues with Mangos already.

But it doesn't have anything to do with multiprocessing. It's more of database server's load balancing capabilities and it's deployment on a separate machine. I couldn't think of anything more than vmaps.

What are performance bottlenecks in Mangos anyway? Suppose we put _lots_ of memory into server, what will be the next candidate for optimization?

I would prefer a solution that doesn't use multithreading in it's purest form (as concurrency of peer threads) - using asynchronous calls to other threads to complete tasks that would otherwise stall the server and just picking them up when they're done (and we've used the time to handle other messages).