Backfill flow diagram.mmd

Backfill flow diagram.mmd

Thanks for an updated, applied your version to this gist as revision 5.
As I see here you introduced a change to Assign operation which now will holds a new BackfillID argument, in that way we can do both operations in one place.

A new version proposed by @scosgrave , revision 6

This revision tries to solve the problem of having a second or third round of match making complete prior to the first one getting an allocated game server. This situation might happen if game server allocation happens asynchronously to match making.

One potential issue with this flow is that it breaks one of the properties of the Director. Usually the Director knows which tickets have been assigned because it is the one calling AssignTickets, but in this flow, if a 2nd match making round completed before the allocation happened, then the Backfill service calls AssignTickets on the tickets that are in the unassignedTicket array. The Director has no idea that those tickets have been assigned. It could find out that they were assigned if it called WatchAssignments on tickets that were in the unassignedTickets array, but that would require the Director to create a go-routine per unassignedTicket, which doesn't scale well. It would be better if the Director's domain name, or IP, and port were sent in with the FetchMatches request, and saved with the Backfill ticket. Then the Backfill service could call an API on each Director associated with the Backfill ticket, to notify the Director that these tickets were assigned.

A second option could be the create a new API on the FrontEnd called WatchManyAssignments which could get the assignments for many tickets with one request. This might cut down on the number of go-routines watching assignments from the Director, but again, it is also possible it could degenerate into a single go-routine per ticket.

I don't think trying to watch the tickets from the Director is going to work. I think the most efficient approach is going to be having the Backfill or OpenMatch Backend notify the Director that a ticket, or tickets, have been assigned. Or, we need to come up with a different flow.

One more note about the last sequence diagram that was posted.
When Matches are returned to the Director, we should always populate the new tickets that were added to the Backfill in the tickets slice. The reason for this is the Director can't tell which tickets in the unassignedTickets array were most recently added. If we put the newly added tickets in the tickets member, then the Director can tell the newly added tickets from the existing ones in the unassignedTickets slice on the Backfill ticket.
Based on this idea, here are some example responses to the Director, and their meaning:

Tickets T1, and T2 were matched together, but the match is not full, so a Backfill Ticket was created. This is the first time any tickets have been associated with this Match, so needsAssignment is True, and the Director should allocate a game server for the Match:
Match(tickets: [T1, T2], backfillTicket{ID: BF1, needsAssignment: True, unassignedTickets[]})

Ticket T3 and T4 were added to the Backfill Ticket, but the game server allocation for the match hasn't completed yet, so they were added to the unassignedTickets slice:
Match(tickets: [T3, T4], backfillTicket{ID: BF1, needsAssignment: False, unassignedTickets[T3, T4]})

Tickets T5 and T6 matched into this Backfill Ticket, but the game server allocation for the match hasn't completed yet, so they were added to the unassignedTickets slice:
Match(tickets: [T5, T6], backfillTicket{ID: BF1, needsAssignment: False, unassignedTickets[T3, T4, T5, T6]})

Tickets T7 and T8 matched into this Backfill Ticket. The game server allocation has already happened, so the Director should be able to get the connection info from the Backfill Ticket, and call AssignTickets right away without doing any game server allocation:
Match(tickets: [T7, T8], backfillTicket{ID: BF1, needsAssignment: False, unassignedTickets[]})

Made a new diagram (rev 7), updating current gist.
The idea here is that Director always would perform assignments.
It can skip the backfill ticket for some reason, so it can have more options how to treat unassigned_tickets. He can use some of them for instance, and UpdateBFTicket with the rest, so later on for example on delete all UnassignedTickets could be returned to the pool of tickets. This way we don't have the only one implementation contained inside OM Core.

An idea is to add one more bool field to the Match - allocate_gameserver, it should be set to false every time but only in the first match output to the director the Match would contain allocate_gameserver = true.