Menu
I'm currently writing a simple cross platform app with Node.js on the server and web/iPhone/Blackberry clients. Bandwidth and latency requirements are similar to something you would see in an IRC "party game" or any chat system. I've developed the web client using HTTP long polling (speaking JSON both ways).
For iPhone/blackberry I could use the built in HTTP libraries to talk to my current implementation, or I could write a socket listener on the server and talk to it using sockets. Is there any advantage to doing so? Why do non-browser HTTP clients seem to be discouraged?
596
asked Aug 16 '10 05:08
Long polling takes HTTP request/response polling and makes it more efficient, since repeated requests to a server wastes resources. For example, establishing a new connection, parsing the HTTP headers, a query for new data, response generation and delivery, and finally connection closure and clean up.
Area of usage. Long polling works great in situations when messages are rare. If messages come very often, then the chart of requesting-receiving messages, painted above, becomes saw-like. Every message is a separate request, supplied with headers, authentication overhead, and so on.
When the wait time for the ReceiveMessage API action is greater than 0, long polling is in effect. The maximum long polling wait time is 20 seconds.
The poll() API allows simultaneous connection with all descriptors in the queue on the listening socket. The accept() and recv() APIs are completed when the EWOULDBLOCK is returned. The send() API echoes the data back to the client. The close() API closes any open socket descriptors.
Can't speak to iPhone as I don't know enough about the technical details of the network stack, but for BlackBerry HTTP requests from the browser are treated differently from app-initiated requests in general. BlackBerry as a solution consists not just of a device-side TCP/HTTP stack, but the BlackBerry service, which includes (depending on if you're enterprise or not) a BlackBerry Enterprise Server with Mobile Data Services (BES/MDS) hosted on your enterprise network, or a Research In Motion hosted BlackBerry Internet Services (BIS) server, which proxy all connections from the mobile browser. These servers can do a lot of things, including handling some aspects of cookies, authentication, and content transcoding to make content more consumable by the mobile device (images and the like). For a BES/MDS they can even act as the secure endpoint in an HTTPS connection.
Anyway, this also means that a lot of the functionality you'd expect from a normal TCP/HTTP connection actually happens off the device, and so can be controlled by a carrier or enterprise or RIM. Bare-bones sockets are different because the various servers in the middle can't make as many assumptions about a TCP socket as they can about an HTTP connection, so they can't mess around with your HTTP requests. A lot of BlackBerry apps actually end up writing their own HTTP client on top of the socket layer for that very reason, so if you have to do something like an HTTP long poll (Comet?) definitely write it on top of the socket connection, not the built-in HTTP connection.
81
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
