I need to transfer pictures between client (the user`s mobile app) and server by http over internet, but as you know,large pictures can seriously affect service performance, i wonder is there an efficient way to transfer it.
Thanks in advance.
Related
This is not a specific coding question but more a research project.
I am very interested in streaming services. To be more specific, I am interested in streaming audio from a server to a device. I do understand the basic logic behind it but I want to get better knowledge in these things.
I would like to try implementing a streaming server and a streaming client (server on mac and client on iOS) but I am having some trouble finding any pages that offer "tutorials" on how its done. I have managed to get the client side somehow and in its example it is playing stream from shoutmedia. How can I implement the server side? I would prefer it in C++ (server in Qt for example would be a bullseye) but any links will be appreciated.
I think that streaming is quite an interesting topic and any links will be appreciated.
Thanks!
I have to devise a push notification plan for some mobile devices where push is not yet officially supported by C2DM / APNS / BES ,etc. MQTT was also a good option but I could not get an MQTT Client for my required platform. (Blackberry Playbook, ActionScript only)
Going back to basics, I had the options of Long Polling and streaming. Streaming using a high keep-alive value seems good to me, as the development of the mobile app (it is not a browser) and the server code are both in my control. To maintain the connection open, I just need to ping the server occasionally.
What issues I may be facing in this approach ? I understand this would constantly open an HTTP connection from the device to the server. Would the battery life of mobile device drain quickly just by persistently opening a server connection ? ...Afterall the data is not being transferred, just by keeping the connection open...right ?
You might want to consider Urban Airship or take a look at this realtime technologies guide.
If realtime really matters, I'm talking about seconds or milliseconds, then a realtime web technology using WebSockets or HTTP Streaming is your best option as they deliver updates the instant they are available. This sort of thing is best suited to the sort of application that a user is actively using during a reasonable period of time where they need instant notifications or are collaborating/chatting with others.
WebSockets are probably a better standard to be using with longer term technology considerations in mind since they are the first standard for full duplex bi-directional communication between a client (mobile, web, desktop) and server.
What platform could you not find an MQTT client for? http://mqtt.org/software lists clients in just about every language I can think of and more than I'd like to bother using. The mosquitto C client library is very portable.
For battery life, it really depends what you're doing between the keepalives...
If you app runs in a country where the network isn't in the best shape, then having all your clients keep a connection open can put strain on their infrastructure (assuming you are that popular).
Battery life is the other consideration, yes, a lot of devices aren't that efficient in keeping an idle radio/3g connection open and it drains the battery a lot faster than not having a connection open.
I've just started dabbling in some game development and wanted to create a simple multiplayer game. Is it feasible to use HTTP as the primary communication protocol for a multiplayer Game.
My game will not be making several requests a second but rather a a request every few seconds. The client will be a mobile device.
The reason I'm asking is, I thought it may be interesting to try using Tornado which reportedly scales well and supports non blocking requests and can handle "thousands of concurrent users".
So my client could make a HTTP Request, and when the game server has somethign to tell it, it will respond to the request. I believe this illustrates what some people call the COMET design pattern.
I understand that working at the socket level has less overhead but I am just wondering if this would be feasible at all given my game requirements? Or am I just thinking crazy?
Thanks in advance.
Q: Is it feasible to use HTTP as the primary communication protocol for a multiplayer Game.
A. Using HTTP as a communication protocol may make sense for your game, probably not, but that's for you to decide. I have developed applications for Windows Mobile, Blackberry, Android and iPhone for just over 10 years. All the way back to CE 1.0. With that in mind, here is my opinion.
First I suggest reading RFC 3205 as Teddy suggested. It explains the reasons for my suggestions in detail.
In general HTTP is good because...
If you're developing a browser based game - flash or javascript where you don't create the client, then use HTTP because it's built in anyway and it's likely all you can use.
You can get http server hosting with decent scripting super cheap anywhere
There's a ton of tools available and lots of documentation
It's easy to get started
HTTP may be bad because...
HTTP introduces huge overhead in terms of bandwidth compared to a simple TCP service.
For example Omegle.com sends 420 bytes of header data to send a 9 byte payload.
If you really need comet / long polling you'll waste a lot of time figuring out how to make your server talk right instead of working on what it says.
A steady stream of http traffic may overload mobile devices in both processing and bandwidth, giving you less resources to devote to your game performance.
You may not think you know how to create your own TCP server - but it really is easy.
If you're writing the server AND the client, then I would go straight to TCP. If you already know python then use the twisted networking library. You can get a simple server up in an hour or so just following the tutorials.
Check out the LineReceiver example for a super simple server you can test with any telnet client.
http://twistedmatrix.com/projects/core/documentation/howto/servers.html
WRT:
"my client could make a HTTP Request, and when the game server has somethign to tell it, it will respond to the request."
This is not how HTTP is supposed to work. So, no, HTTP would not be a good choice here. HTTP requests timeout if the response is not received back with the timeout (60 seconds is a common default but it would depend on the specifics).
Please read RFC 3205: On the use of HTTP as a Substrate, which deals with this.
With the target platform being a mobile device (and the limited bandwidth that entails) HTTP wouldn't be the first tool I would pull out of the box.
If you just fancy playing with all this technology, then you could give it a go. Tornado seems like a reasonable choice, if the example on the web site is anything to go by. But any simple server-side web language would suffice for serving up the responses you need at the rate you have mentioned. The performance characteristics are likely to be irrelevant here.
The COMET method is when you leave a HTTP connection open over a long period. It is primarily there for 'server push' of data. But usually you don't need this. It's usually much more straightforward to make repeated requests and handle the responses individually.
I would like to create a browser-based network game. To ensure it can be used by as many people as possible, I'd like to embed all the traffic in standard HTTP packages.
Assuming I use IIS as my back end, how should I code this to minimize latency?
Is it reasonable to start with an ASP application of some kind (ASP.NET MVC perhaps) using shared state in memory? Or should I plan from the outset on writing some kind of IIS plugin of my own? Or should I abandon IIS and write a custom server instead?
Is it reasonable to start with each client repeatedly querying, say ten times per second, or should I make the data more stream-like somehow (and if so how)?
This can work just fine, but you're going to have to do something less "conventional."
To make this work, don't do individual requests, keep the request open and then transmit data with the open connection.
You could try using a protocol like Bayeux, but there are no rules here.
Here's an example with ASP.NET using COMET.
Designing an app to hit a web server 10 times a second is not a good idea. Web servers are designed for less frequent client requests and probably larger processing times and reponse sizes than your game will be using. That's not to say a web server wouldn't be able to cope just that it would not be an efficient client-server match.
For any type of app that requires multiple packets per second you really should think about a lighter protocol than HTTP which is fairly verbose. For example if your game needs to send 4 bytes to register a user's battleship co-ordinates you don't really want to transmit an extra few hundred bytes of HTTP headers.
I'd recommend a browser plugin technology like Siverlight of Flash. Both of those support TCP socket connections. You would need to write your own server to sit at the other end of the TCP socket. With that approach you'd also have the advantage of being able to push data out to the clients without having to rely on client polling mechanisms which are required with HTTP, e.g. AJAX.
One problem you will face with standard HTTP messages is the size (and lack of control) over the header data.
I was involved in the design of a flash game which was played by several million people. We needed to communicate with the server every few seconds and ended up using ultra-lightweight JSON messages to save on bandwidth and keep it snappy.
Size of JSON message: 16 bytes
Size of HTTP Header: 200+ bytes
HTTP is not really a good protocol for high traffic, low latency requirements. It was designed for larger, less frequent request/response models and has status codes like 304 Not Modified for this very reason.
You'll probably want to drop down to a custom TCP/IP implementation.
I'm developing a multi-player game and I know nothing about how to connect from one client to another via a server. Where do I start? Are there any whizzy open source projects which provide the communication framework into which I can drop my message data or do I have to write a load of complicated multi-threaded sockety code? Does the picture change at all if teh clients are running on phones?
I am language agnostic, although ideally I would have a Flash or Qt front end and a Java server, but that may be being a bit greedy.
I have spent a few hours googling, but the whole topic is new to me and I'm a bit lost. I'd appreciate help of any kind - including how to tag this question.
If latency isn't a huge issue, you could just implement a few web services to do message passing. This would not be a slow as you might think, and is easy to implement across languages. The downside is the client has to poll the server to get updates. so you could be looking at a few hundred ms to get from one client to another.
You can also use the built in flex messaging interface. There are provisions there to allow client to client interactions.
Typically game engines send UDP packets because of latency. The fact is that TCP is just not fast enough and reliability is less of a concern than speed is.
Web services would compound the latency issues inherent in TCP due to additional overhead. Further, they would eat up memory depending on number of expected players. Finally, they have a large amount of payload overhead that you just don't need (xml anyone?).
There are several ways to go about this. One way is centralized messaging (client/server). This means that you would have a java server listening for udp packets from the clients. It would then rebroadcast them to any of the relevant users.
A second way is decentralized (peer to peer). A client registers with the server to state what game / world it's in. From that it gets a list of other clients in that world. The server maintains that list and notifies the other clients of people who join / drop out.
From that point forward clients broadcast udp packets directly to the other users.
If you look for communication framework with high performance try look at ACE C++ framework (it has Java bindings).
Official web-site is: http://www.cs.wustl.edu/~schmidt/ACE-overview.html
You could also look into Flash Media Interactive Server, or if you want a Java implementation, Wowsa or Red5. Those use AMF and provide native functionality for ShareObjects including synching of the ShareObjects among connected clients.
Those aren't peer to peer though (yet, it's coming soon I hear). They use centralized messaging managed by the server.
Good luck