Timeouts – What They Are and How They Hit Your Revenue

In buying and selling travel products there are countless applications, servers and networks talking to each other every day 24/7 to make travel requests, receive responses and offers, do deals (confirm deals or sometimes cancel them) and ensure payments end up in the right place. Basically in the world of Internet travel bookings there are an awful lot of messages being pumped around the system, much of it in XML. Thank goodness for APIs hat provide the underlying standards to enable the exchange of information (and XML messages) between systems.

With so many systems talking to each other, there are inevitably stresses and strains as well as rules and protocols. This is where timeouts come in. Timeouts are signals generated by an application or a device that has waited a certain length of time for some input from some other system in the chain but has not received it. Timeouts are designed into the mechanics to avoid systems sitting idly waiting for input that may never come. They are there to keep the various systems from getting clogged up. Essentially timeouts can be seen as a fundamental fall-back mechanism. They can also be indicators that systems are under strain or not performing properly. Timeouts are closely connected to response times, also a rich topic in the world of online travel commerce and one which we will cover in more detail in the next article.

There are typically two types of timeouts that can be set when connecting systems via the web: the connection time-out and the read-write requesting timeout.

• Connection timeout is the maximum amount of time allowed when establishing the bi-directional socket connection between the client and server. Behind the scenes socket connection involves resolving the domain name of the server to an IP address, and then the receive server opening a port to connect with the client’s port. Opening the port allows the message to be delivered (i.e. written).

• Request timeout is the timeout that limits the amount of time a client system will wait to receive a response from the server. If a server is faulty or overloaded it may take a long time (or forever) to respond to a request. This timeout limits the amount of time the requesting system will wait and listen for the returning server to respond with a written message (usually containing the requested offers).

Having a fast and reliable platform and network infrastructure is crucial and relies on having connections and processes that support timeouts. This involves three main steps: connecting to the external server, reading and writing data from and to it, and, at some point, closing the connection.

Timeout Ramifications

With travel distribution being so competitive how and when timeouts occur is crucial. Speed of response in delivering offers to requests lies at the very heart of success or failure.

Timeouts should happen automatically. When no response is received because the request failed to reach the travel supplier or intermediary server, then the transaction can be treated simply as a failure – the transaction was not received, and therefore not submitted to the database for a response.

Alternatively, it is possible that the request did reach the server and placed the request, but the response did not make it back to the requesting server within the specified timeout period. In other words the server may have been busy processing the request, but got timed out before it had gathered the results for onward sending.

Of course another scenario is the server took longer to respond, to the point that the requesting server was no longer interested in the results, but failed to send a timeout signal to say ‘stop processing you are too late’.

What Timeouts mean to online travel companies

Timeouts in the middle of a search request are not good news as it means quite simply that when requests are made, offers that don’t make it in time can’t be served up and included in the end results presented to the final customer. Not being included at this stage as a result of a timeout means missed profit opportunity. Even worse, if a supplier has been timed out in one request, the requestor may decide to exclude the supplier from other requests for a given period of time.

Online travel distribution is all about being able to respond and satisfy in real-time. Online companies depend on servers being able to query databases and respond very quickly. It is also vital that when systems are not replying fast enough that this is detected and its causes mitigated as quickly as possible.

The travel supply chain is based on supplier relationships. If a player wants to stand out among competitors it is vital to have access to inventory that delivers to customers the best selection of hotels at the most competitive rates. OTAs or tour operator work with multiple accommodation wholesalers simultaneously to fulfil this need.

The traditional wholesaler serves a fragmented market by contracting with hotels on the supply side and travel agents on the sell side. Essentially the wholesaler has a front door to the travel product sellers and a back door to the hotel suppliers. To manage supply and demand across the market wholesalers also build relationships with each other. Travel product requests and responses through APIs is what keeps them all connected.

A Real-life Example

When a traveller uses an OTA to buy a hotel experience in Paris, he is looking for options to choose from that meet his search criteria. The OTA uses its supplier relationships (or possibly its own inventory) to fulfil the request as best as possible and as quickly as possible. In the cut throat competitive world of travel – speed is of the essence, because several players will have the opportunity to respond and compete with inventory. So it comes down to having the right inventory at the right price in the right time. All achieved with XML messages across the supply chain.

So timeouts have a critical role to play in the plumbing of online travel. If you are in the business of sending requests you want to make sure that the request is error free (i.e. includes the right codes) and is sent to the right place. With very large inventory databases, it is possible that the receiving server suffers an error pulling up the requested data and is unable to send anything back to the requesting server. In this instance the request makes it to the server, but the server gives up and never sends anything back. In a real-time travel context, if this happens, opportunity to present an offer is lost for good. No offer on the table equals zero chance of conversion to booking.

Of course, API traffic is network dependent so while servers are working fine, requests or replies may still be lost to network or infrastructure issues. And capacity, either network related or server, can become over burdened with requests from other servers. Seasonal travel booking periods or one-off events can trigger such loads.

Where Analytics comes in

Of course, a server connection timeout error does little to tell you what went wrong or why the error happened: it just identifies that the error occurred. Timeout errors can happen for a number of reasons. The server, the requesting device, the network hardware, the network connection or even the application can be at fault.

And in the case of travel, the request itself maybe erroneous and therefore difficult to fulfil in the given time. In other words, blame can be parked almost anywhere along the chain. With industry response time standards in seconds rather than minutes – it is imperative for companies in the supply chain to monitor all their technical elements to reduce timeouts and understand how and why they occur. A closer look at XML data can also identify instances when timeouts are not triggered even though responses are not being presented quickly enough to be considered. Spotting something like this helps suppliers mitigate such futile use of precious server resources.

In today’s online e-commerce world, while it is imperative to constantly and comprehensively monitor the health and performance of systems and networks, it is also makes sense to read the message flow with intelligence. Without proper monitoring measures, distribution or IT managers can quickly lose visibility into the performance of servers, applications or networks with detrimental consequences for business, especially where online transactions are involved. It is also important to use such metrics to identify whether your systems are at fault or those of a connecting partner or indeed customer. Knowing how your systems are behaving in real-time is important insight that can help you succeed.