Hi John On Fri, 24 Aug 2012, John MacAuley wrote:
The only issue we have is that the RA will not know the connection ID so will not be able the query the reservation in its "reserving" state, or to see if it missed a confirmation message.
Yes, that is the main problem. However with solution A, we get into the issue that if a requester chooses the id, it does not know if the connection id is actually available (of course this can be reduced to a probability of essentially 0 - as long as everybody plays nice).
Perhaps, and I am just throwing it out there, we might consider reworking the ACK to the reserve.rq to return the allocated connection Id? Maybe a new mechanism?
I think this is good (I'm still not a fan of the RPC callback), but for what we have I think this is good. Do we still need to have these as UUIDs? I am not against UUIDs, but I still do not see the point of forcing them at protocol level. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet