"Indian Railway Catering and Tourism Corporation (IRCTC) is a subsidiary of Indian Railways that is responsible for handling catering, tourism and online ticketing operations of the indian railways" - Wikipedia.
We all know IRCTC as we see it whenever we book a ticket, we drink tea/coffee in a railway station, etc. In this post, i am going to talk about one of the ever existing nightmares of indian train travellers - Tatkal ticket booking.
Indian railways has a famous system known as Tatkal (which in sanskrit means
instant) reservation scheme which allows us to book tickets two days before the departure of the train throughout the year. This is like the golden gem for last minute planners. Oh this seems great, i can book a ticket two days before? Of course its not as simple as it sounds and there are loads of hassles around. Since tatkal bookings open only two days before the date of departure of the train, bookings are opened by 8 AM (IST of course :P) and you might by now be thinking, 8 AM - No big deal. I can be in the railway station booking counter by even 7 AM. You're still not doing good as there are many people who are already in the booking counter queue waiting from 3 or 4 AM in the morning or probably from even the previous night (yes, it happens!).
Ok, so the booking counters are flooded by persons on morning, i even have a better way now, i am a very modern person, i don't go to the booking counters and stand in queue for booking rail tickets, i just boot up my system, point my browser to irctc.co.in and voila! I have the ticket booked in a matter of seconds. Well, this process seems to be fairly trivial and simple. But unfortunately there are even bad hassles involved in this process.
First of all the website itself. People who travel a lot by train might always be cursing the government website irctc.co.in for screwing up their last minute travel plans almost all the time. The website server is either down (meaning the website is unaccessible) or doesn't provide service as expected (which is an obvious requisite). The following is the timeline of what generally a layman does for booking a tatkal ticket in irctc.co.in:
- 7.45 AM - Open all possible browsers (internet explorer, firefox, chrome, safari, opera, etc.) and login a session in every browser
- 7.46 AM to 7.59 AM - Try to fill in some fake forms and keep all the sessions active by clicking on some link or the other so that you don't get the "Sorry your session has expired, possible reasons are...". At this timeline you might also see the "Sorry e ticket can be booked only after 8.00AM" alert message frequently
- 8.00 AM - With all tension and hurry, type in all the travel details (probably in the quick book form) and click on "Go" to just see the loading mouse icon or more probably the "Service Unavailable" error page
- 8.00 AM to 8.15 AM - After lots of refresh in various browsers, at last you have seen a blue color page in one of the windows and in excitement you type out all the travel details and after encountering a few more "Service Unavailable" error messages, you might at last get until entering the payment gateway credentials (yet going beyond this point is still a question mark)
- 8.15 AM to 8.30 AM - Totally unexpecting it, either you have got the "Service Unavailable" error message again or there are no more tickets available in the train you wanted
- 8.31 AM - You spend a minute grumbling and scolding irctc.co.in website and think of it as yet another tatkal booking attempt that failed and you look for other alternatives (most of the people goto www.kpntravels.in by 8.32 AM)
Second of all, even if the website was really good and if it could offer everything travelers want, the load that is built on the irctc.co.in webserver is enormous during the 7.55 AM to 8.30 AM period. Hence, booking a ticket online now, becomes a matter of luck.
For people who don't get how it is about luck now, let me explain further. Consider you are in a bar wherein a bartender gives away drinks to random people. There are way too many people than the bartender can handle and the bartender does not have any intelligence and hence he simply gives away drinks to random people as long as it is available. Thus, if you are lucky enough, you'll get a drink. The same is the case here where the bartender is the irctc web server and your ticket booking requests are the requests made to the bartender for drinks.
And one more thing about this online booking is that there are agents available in various parts of the country who assure that they can book a ticket for you. I'm still not sure how that is possible violating the pigeon hole principle ( simply stating - according the pigeon hole principle (probably a stricter version of it), if there are only x tickets available, only x persons can travel but there are quite easily much more than x agents all around the country ). So that is one glitch that if you can just pay how much ever extra the agent asks, are you sure you'll be travelling on the required train? The answer is no. I have seen many cases where the agents too fail to book a ticket for you in the required train (and you're forcefully redirected to kpntravels.in again or may be to jetairways.com if you are rich).
Ok, so whats the point in all this? The point i wanted to say is, today (not exactly today, sometime in the past few days) i came up with a dry thought of doing something so that you can escape the threatening "
Service Unavailable" error messages. Now going back to the bartender example, the bartender does not have any intelligence and hence you think you can do nothing about it. But what if you can slip in an extra few bucks so that bartender is sure to give you the drink before its done. Ok, this is fine for the bartender example, but how do we bring this into picture with a web server in the place of a bartender?
Seems impossible !! Thats when my TCP/IP knowledge kicked in and made me think about the flags in a TCP packet (non technical people [or even some technical people :P] might not be able to follow this, but read on as i'll try to give another simple example later). Yeah, if you are a networks expert, you might have probably guessed the thought that i had in mind by now. There are eight bits allocated in a TCP Header that are known as flag bits. Our hero (i mean the one we are interested in) is a flag called URG flag or the URGENT flag. As the name suggests, this flag helps us to override the routine queuing done by the TCP/IP stack of the operating system.
Hey stop all this crap. I dont get a word. - Ok, let me give an example again. Consider a courier service office where they receive many parcels of letters daily and process them in the order they arrive (i.e.) a parcel of letters coming in by 7 o clock will be processed before the parcel that came in at 8 o clock. Now, there is a special override for this that if a parcel carries a red flag in it, then it will be processed immediately irrespective of the time it came in.
This is the same kind of scenario that i am talking about. The operating system's TCP/IP stack processes all the packets (requests sent by you to book tickets) in the order they arrive except for the only exception that is the packets with URG flag set will be processed first irrespective of the other unprocessed packets (requests sent by others to book tickets) in the queue which had came in earlier. A question might be raised here that what if the other requests also has the URG flag set (or what if all the parcels have the red flag in them) ? The answer to this question is, as long as people/agents use only a web browser to book tickets, there is no possibility that the URG flag will be set in the packets that are sent from the browser as it is disabled by default. Also, i think this might be a good approach as it is in the transport layer, it is not possible for the application to override this behavior (because this is the behavior of the TCP/IP protocol stack of the operating system).
So, my high level idea is that, there could probably be an application developed, that simulates the web browser in requesting the irctc web server (maintaining login sessions, etc) and at the same setting the URG field in every packet sent. For TCP/IP experts, of course there are implementation issues like where will the urgent pointer point to and much more which can be answered only when such a system is implemented. (And yes, i have plans of implementing one such system).
Ok now what? As usual, any comments are welcome. And anyone who could go ahead and implement such a system in a jiffy are welcome to do it. For more details, pings are always welcome.
P.S.: I really enjoyed writing this post as everything was getting into its place with a great flow and i love the way i have organized this post. :-)
-Vignesh
