Modern data communications are usually based on the client-server model. In that model a client, such as a web browser submits messages to servers dedicated to perform certain functions. Those servers provide resources to process messages, to send messages over a communication link, to service the messages, to receive return messages, to process the returned message, and then to submit the returned message to the client. This client-server model works very well, at least in part because the client, the servers, the communication network, intermediate entities, and the messages all follow standardize sets of rules. Individual entities can be designed independently based only on the requirements of that entity's set of rules.
Extending the client server model is the concept of proxies. A proxy is a device, system, or application that acts as an intermediary for handling requests from a client for resources such as a file or a web page or access to a network. One of the most useful proxies is the so-called proxy server, which is a computer system (or an application that runs on a computer system) that acts as an intermediary for requests from various clients that want services from other entities. A middle manager of sorts that receives data and passes it along as required. A proxy server may be a local proxy, which implies that the proxy server is in the same domain as the client, or a remote server which implies it is not in the same domain.
Also extending the client server model are standard communication protocols such as the Hypertext Transfer Protocol (HTTP), the Hypertext Transfer Protocol Secure (HTTPS), the File Transfer Protocol (FTP), the Simple Mail Transfer Protocol (SMTP), the Internet Message Access Protocol (IMAP), the Post Office Protocol (POP), and the like. While these and other standard protocols have proven to be very flexible and highly useful they may not be optimal in all applications. For example, in some mobile data communication systems non-standard protocols may provide better data feed-through.
Many mobile applications are moving away from standard protocols and towards vendor specific proprietary protocols that can improve data communications using the vendor's products. For example, Google utilizes a non-standard Transmission Control Protocol (TCP) port 5228 while the “WhatsApp” mobile application uses a customized version of the Extensible Messaging and Presence Protocol (XMPP). Other applications such as Skype and Yahoo mail use their own proprietary protocols while others such as Urban Airship's push notifications protocol is used by various vendors.
While standard and custom protocols have both proven highly useful, each protocol still must pass over a distributed system of local proxy and/or proxy servers as a data stream. Such distributed systems almost always implement the Transmission Control Protocol (TCP). TCP produces an ordered, error-checked data stream of octets that pass between programs and computers connected to a network.
One major concern of modern communication system architectures is time. Data transmissions from a client over a local proxy servers to the next server to the next and finally to a host proxy server which services the request takes time. Responding to a query also takes time. Returning the response to the client takes more time. Meanwhile the network is handling the traffic of other users. Once a message is sent, a client cannot know that the link between itself and the host proxy server remains intact. Any failure in the communication link conceivably would leave the sending browser waiting for a response that will never come. This is a very serious problem in mobile communication networks since mobile devices change links as they move from one location (cell) to another.
A common solution to the foregoing is to ensure that the communication link remains viable by incorporating “keep-alives” or “heartbeats.” A “keep-alive” is a short message sent between devices to verify that the communication link between them is intact. In some systems “keep-alives” actually do keep the link open since if a keep-alive message does not occur in a given period of time the links will self-break to avoid hanging up and to re-establish communications. Unfortunately the actual content and format of keep-alive messages depends on the specific communication protocol that is being used. While a client will recognize it's keep-alive on a mobile network and can send its “correct” keep-alive, intermediate proxy servers may not. Thus in the prior art, intermediate proxy servers had to simply pass on all messages. This increased congestion and caused traffic delays for non-clients.
Maintaining link integrity is particularly important when using mobile devices such as cell phones. The reason for that is that mobile devices are “handed” off from one cell to another as the mobile devices move. Communication link changes are common and the proper functioning of each new cell link is important.
The importance of keep-alives and the fact that keep-alive content and form depend on the communication protocol being used makes protocol agnostic system architectures highly desirable. One simply wants a system architecture that can handle anything. Thus, a system architecture that is protocol agnostic would be very useful. Preferably such protocol agnostic system architectures would support data traffic optimization in a wireless network. Ideally such protocol agnostic system architectures would support data traffic optimization using intelligent keep-alives which can be delayed or advanced and/or blocked to enable improved non-client interactive traffic in a mobile network.