How does BAP know when all bpps have responded to search

[venkatramanm]

After firing search, BAP today doesnot know if all BPPs have responded or BAP needs to wait to collect more responses.

Let's say gateway broadcasted search to 7 bpps and responses have come within 3 seconds from all BPP. TTL was 20 seconds. Why wait for 17 more seconds.? 🤔

[ravi-prakash-v]

Good point. There could be two approaches to solve this.

Solution 1:
BG can send back the number of BPPs (n) it has broadcasted the Intent to as metadata the ACK response. The BAP will count the total number of unique responses and wait till it is equal to n or until the TTL expires whichever is sooner.

Solution 2:
After it has forwarded the responses from the BPP the BPP can send an on_search/end response to indicate the end of the search cycle.

IMHO, I prefer Solution 1. It keeps the BG stateless. What do you think?

[thejeshgn]

Usually ACK will be returned by the input side QUEUE doing minimal non business validation.

Any real response comes from the business system and that will be ASYNC. System may not be able to send you the number of BPPs successfully as part of SYNC ACK.

[pkapustin]

@thejeshgn Not sure about the other implementations, but our gateway is very simple and doesn't have any complexity like this. We can easily return the number of BPPs the request will be forwarded to at once. Personally I don't see why others shouldn't be able to do the same.

Also, please check #144 regarding sync APIs.
We already started using sync APIs for everything except search / on_search in the taxi network and are planning to use for the integrations in the public transport network.
It makes things much simpler for HTTP implementations and reduces possibilities for errors.

[pkapustin]

@thejeshgn I do see your point about queues though, in some cases it may not be feasible to return a response immediately (for example, on_search and for events that originate from the BPP).
But I don't think it is really the case with the number of BPPs the request is going to be forwarded to, I think it should be possible to return this at once.

[thejeshgn]

@pkapustin sure. But I think this is generally against the policy of ASYNC requests. May be @core-wg-admin can clarify.

[pkapustin]

Yeah, essentially we thought that sync vs async could be up to the network.
It can be quite beneficial to use sync for many APIs in HTTP implementations, see #144.

Of course, some things will have to stay async, like on_search and events that originate at the BPP.