Knowing When to Use Which Protocol
As I've just explained, the GCF makes a number of networking options available to applications, but there are a few things you need to know in order to decide which to use when. In the case of MIDP, the specification only requires support for HTTP, although many devices support datagrams and sockets as well, because these protocols are needed to implement HTTP. However, before making commitments to datagrams or sockets it is a good idea to make sure they are supported on the platforms you are targeting.
Because HTTP is guaranteed to be supported by MIDP this is usually the best protocol choice due to portability. HTTP moves through firewalls easily since it generally operates over port 80. However, of the three protocols discussed, HTTP incurs the most overhead, which may drive up the user's cost of using the application on the network.
Datagrams, on the other hand, tend to have far less overhead and can be easier on the end-user's budget. The caveat, as discussed previously, is that the application must take on the task of ensuring that all data arrived at the other end and that the order of that data received is correct.
Finally, sockets fall somewhere in the middle of HTTP and datagrams in that data sent over a socket is managed by the protocol, but requires fewer network resources than HTTP. This means that the application does not have to concern itself with making sure data is received on the other end. Sockets are generally a lighter-weight option over HTTP since the application controls when the end points communicate. HTTP, on the other hand, must make several trips between the end points to exchange header information as well as the data.
The GCF provides a lot of functionality and standardizes how connections are established throughout the J2ME architecture. The GCF is extensible as well, allowing manufacturers to support their own interfaces and connection types. In some cases a manufacturer may use the GCF to support streaming multimedia content with a special connection or for establishing connections to a GPS receiver. Having this kind of flexibility prevents J2ME from being constrained to a common set of protocols while maintaining consistency throughout the architecture.