On Wed, 2005-06-08 at 17:53, James Lentini wrote: > On Wed, 8 Jun 2005, Hal Rosenstock wrote: > > halr> On Wed, 2005-06-08 at 11:44, James Lentini wrote: > halr> > We interpreted the above to mean "give the connection protocol as > halr> > much time as it needs to establish a connection, but don't mask > halr> > errors (no path to the remove node, etc.)". For that reason we > changed > halr> > the variable name to DAT_TIMEOUT_MAX. > halr> > halr> But if the REQ is lost, the timeout is really really long (longer than > halr> most will wait for an error). > > If a user doesn't want to wait DAT_TIMEOUT_MAX time, it can pass a > smaller amount of time to dat_ep_connect. Does this satisfy your > requirements?
Is it the intended that the only way out is via user intervention (e.g. ctl-C) ? If one connection attempt (REQ) is made and it is lost, then there is no chance of it completing and the user needs to intervene. If that is the intended behavior, we are there. (This (lost REQ) can even occur when the timeout is non infinite too). An alternative (as Sean suggested) is to continually retry (at a periodicity below the supplied timeout) until the time period specified expires. That seems to be better (at least to me and Sean) in terms of handling the lost REQ case. As retries is not part of the API for connect, I would presume the implementor is free to what they want under the covers of dapl_ib_connect. -- Hal _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
