I’m pondering prototyping a project that is perhaps a little different from the norm. There are two possibilities as the app has to communicate with an existing server.
The client connects to the existing (non-unity3d) app and receives position updates over tcp/ip or http requests.
The client receives data from a unity3d server, but the server receives position information from the external server either over tcp/ip or http.
The existing server currently provides access using http so that would be easier to prototype, and would require no changes on the server. Position updates are sent every 1-5s so it’s not realtime and the bandwidth requirements are very low.
I’m tempted to try 1) over http as this would be the least amount of work but can I use the scripting language to update an object’s position based on information from an external, non-unity3d source?
If your app fits the request/response model, and especially if the server is already implemented this way, then you should be fine using HTTP on the client. What kind of API does the server expose?
Unity’s WWW class sucks quite a bit, though. It doesn’t really support comet, other than long-polling, and it only supports GET and POST. It’s also relatively hard to tell whether it has finished fetching data, without just asking for the data and seeing if an error occurs.
I have found a way to get a comet-like effect through WWW, though, when I was looking for a way to do HTTP-based networking on iPhone without buying Unity Pro. Still, if you’re not targetting mobile, or if you have a pro license for mobile, then you might be better off implementing your own HTTP client on top of .NET sockets, to retain full control over receiving partial results and gain support for more than just GET and POST, as Unity’s WWW class doesn’t support anything beyond that.
If you’re deploying for the web player then the crossdomain policy needs to be served differently if you use a custom HTTP layer.