The best suggestion I can possibly give you is to not make shortcuts in your MMO!
Do not use RPC, it’s too bulky, best to use something like a UDP hardcoded packet, something like, packetHeader\r\ndata1\r\ndata2 (encryption is generally a good idea) as with an MMO, the server will be throwing out packets like a madman, and each client will be receiving UDP packets like it’s the end of the world.
Try to ensure your movement packets are only sent either when the player moves, or if you want to join them with a player status update packet, then send the packet only once every 0.200 seconds, use Unity3D to smooth the animations and you won’t see any real delays!
I personally have written my server from scratch using VisualStudio (C#) and the client is using Unity3D with a lovely Asynchronous background listener for packets. This ensures no packets are lost due to resetting the background listener, and prevents the client from “hanging”.
But then, I have experience working on reverse engineering servers from clients, as well as packet spoofing, sniffing and reprocessing… So yeah, it really comes down to what you want to do. It’s best to create your framework (even if some aspects you know will need to be changes) and once your framework is created, go back over the slow parts, and sort them out by making them run more efficiently.
The more packets sent from the server to one client = the more processing power the server needs, the more download speed needed by the client, and the more processing power of the client’s computer. The smaller size of the packets, the less resources used. Best to send ID numbers rather then names. Specifically in spells, say, a player casts “Heal” you want to shave 3 letters off your packet and just send “1” as the ID number in said packet to the server for interpretation and processing.
It can really be a lot of fun, and quite interesting working on these types of projects. If you want a server to have thousands of connections, you need to ensure the physical box can handle it, and the code is versatile enough not to crash, overflow or corrupt the data.