MapService NodeToPoint response is ambiguous

[Nzen]

When a client sends a NodeToPointRequest to the MapService for some Node, it receives a NodeToPointResponse with only a Point. If a client requests this synchronously, it is clear that the response Point y corresponds to Node x that this client just requested. However, it is not clear how to match requests with responses when sending several asynchronously.

I assume this is a queue, rather than a stack, but I can't tell, as nothing seems to call Map.node_to_point(). I will verify this soon, when my client starts getting node points and estimating where nodes are, so it can approximate airplane moved events to the closest node.

I submit that a response with the point and the node that it goes with constitutes a better message, as it makes the context explicit, rather than implicit. I understand that would be a breaking change to the api.

[tyrope]

I realise this is an old issue; but what's blocking the client from wrapping other parameters into their callback? For example, I store an airplane's id in the variable "callsign" before submitting a new flight plan (another such function that doesn't give feedback from the API):

const callsign = airplane.getId();
let newfp = new atc.UpdateFlightPlanRequest();
newfp = newfp.setId(callsign);
newfp = newfp.setFlightPlanList(path);
airplaneService.updateFlightPlan(newfp, (error, response) => { ApproachClearance(callsign, error, response); });

[Nzen]

Nothing prevents a client from doing so, of course. I guess if my client instantiated a stream observer for each request, that would disambiguate the significance of the NodeToPointResponse. However, I am (was, to the degree that I considered it) concerned that this increases the overhead of deriving the map node points. That overhead is most meaningful as the simulation begins and the client must rush to understand the map in time to route the first plane from its random flight plan to a valid client-controlled one.

As to the ambiguity of the UpdateFlightPlanResponse, the reason I didn't complain about that too stems from the fact that I hadn't gotten far enough to really worry about it yet. I consoled myself that the game would affirm my choice with a followup FlightPlanUpdated event. I acknowledge that understanding the failed request sooner than a (self-imposed) timeout would be helpful in marshalling the correct response.

To answer my earlier questions, the simulation - thankfully - provides responses that imitate a queue rather than a stack. If I studied the Tonic library (which is what handles the Map.node_to_point() endpoint), I would probably find that they corroborate that style of handling requests.

I guess that, if I resume developing my atc client, I should change the endpoints that involve ambiguous responses in the style @tyrope suggested, similar to how TCP creates order from disorder, at cost.

[tyrope]

That overhead is most meaningful as the simulation begins and the client must rush to understand the map in time to route the first plane from its random flight plan to a valid client-controlled one.

You can grab all the map details before starting the simulation. ;)