Since I’ve posted it on the blog and sent out a newsletter about it, you are almost certainly aware of one thing I worked on last week: The launch of the Smith game world. If you haven’t played with Individual Travel Requests before, now’s a good chance to give it a try. Speaking of ITRs: Due to the feature now being deployed in a “regular” game world, I decided to mark the respective roadmap item as done as well. Always a very satisfying thing to do. Progress is slow, but it’s steady 
But Smith aside, you might remember that I ended last week’s devlog on this ominous note:
And here we are in “next week”, so time to reveal what was I was working on 
The issue of unbalanced inbound and outbound traffic isn’t specific to ITRs, but the feature obviously amplifies it due to the way traffic is allocated (filling up from best to worst connection rather than spreading pax weighted by connection rating) and the chance of different pax types being rolled in either direction. So I decided to have a look, especially because the whole subject of return travel was an important part of the Technology Demonstrator project and there still are several items on the roadmap that play into it.
The ASTD worked in a way totally different from the current ORS, because it actually generated and booked every travel request individually…with a dedicated search for outbound and inbound connections and then booking the best pair. This simply isn’t possible with current-generation AirlineSim (and truth be told, the ASTD struggled as well), but there are a couple of options that might come close:
- Do everything as today, but for each successful outbound booking request, store the request parameters. When the destination airport has its next update, load all the inbound booking requests and process them alongside the newly generated outbounds. The biggest advantage is that this would require very few adjustments to the current setup. The major drawback is that it’s still technically two different requests (albeit with identical parameters and a carrier preference) processed in two distinct traffic distribution runs, each with a slightly different context.
- Actually do return searches. This sounds prohibitively computationally intense. And maybe it is. But because demand (and thereby total amount of destinations) would be cut in half per direction (because the return is booked at the same time = factor two) and because searches would still happen in bulk for the whole of the booking window (one broad connection search for all outbound requests, followed by very narrow search for all inbound connections from each destination), it might actually be feasible.
Since this was supposed to be a pleasure project, I obviously went with option 2 
As a first step, I had to implement one major departure from the way the current ORS does things: In the past, AS ran on very beefy physical servers with lots of CPU cores. So back when I conceived the current version of the ORS, I implemented it in a way that can easily utilise a dozen or more cores to process a single distribution request by parallelizing parts of the request. Since then, hosts have become smaller (VMs rather than physical hardware) and CPUs faster. So now it makes more sense to reduce context switches and instead utilise individual cores to the max by running the full search in a single go, but only process somewhere between 2 and 6 requests at a time (depending on resources).
The idea: Run the outbound search to all destinations as efficiently as possible, then run one return search for each destination, constraining the inbound searches as much as possible based on the results of the outbound results. For large airports, this is going to take a while to process. But for many smaller ones, it should be a quick process.
Emphasis on “should” here, of course. This is an experiment. And it’s on-going. So far, I’ve implemented the transition to “single-core processing”. Next week will see me dive into the actual return booking code. My initial estimate was “one to two weeks” (see quote above) and I am almost certainly going to exceed this (also see quote above ). But in my defence: Tomorrow, the simulogics team will convene at HQ, so my dev time will be limited.
One final note (this devlog is already far too long as is): I am not ready to call this experiment “return flight bookings” officially yet, even though a roadmap item by that name exists. Said item has a much broader scope and would require a much longer booking window to actually make impactful decisions regarding return booking behavior (length of stay, staying over a weekend etc.). And I doubt that my current approach will be able to support this. But never say never…