With a two-way handshake only the passive side accepts the connection request (it_ep_accept() or dat_cr_accept()). IT-API defines an optional *three-way* handshake where the active side must *also* call it_ep_accept() before the final connection establishment can proceed.
This does not map to iWARP/MPA in any standard way, so rather than defining a protocol to wrap the first handshake private data, DAT decided to stick with only two-way handshaking. There has been no screaming, so we can presume that *most* applications find two-way handshaking acceptable. However an IT-API provider is free to say that it supports three-way handshaking, and I believe it is implied (if not required) that InfiniBand providers do so. What I do not know is if any actual applications have ever made use of this capability, or if it is only a defensive encoding of a protocol option into an API that prefers not to avoid removal of options that are available at the wire level. DAT emphasized providing a clean API for transport neutral services, and so simply said "use two-way handshaking". In any event, if no support is going to be provided for private data on the second it_ep_accept at the verb layer then that should be explicitly documented, and I'd suggest sending a 'heads up' to the IT-API authors, On 5/19/05, Or Gerlitz <[EMAIL PROTECTED]> wrote: > Caitlin> I believe that an IT-API it_ep_accept() supplies private data > that it expects to be delivered to its peer when the three-way handshake > option is selected. > > Both IT-API it_ep_accept() and DAT dat_cr_accept() cause the provider at > the passive side to send a --REP--, > so how --RTU-- is related to the _accept calls? > > I think you ment to say that exposing two-way handshake means that the > consumer can not supply private data for > the RTU as he is not aware of it (the RTU) being sent? > > Or. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Caitlin Bestler > Sent: Thursday, May 19, 2005 2:16 AM > To: Sean Hefty > Cc: openib-general > Subject: Re: [openib-general] CM private data > > I believe that an IT-API it_ep_accept() supplies private data that it > expects to be delivered to its peer when the three-way handshake option > is selected. > > DAT only exposes a two-way handshake, so there it never requires private > data on the RTU. > > I don't know if any IT-API applications actually require the three-way > handshake. > > > On 5/18/05, Sean Hefty <[EMAIL PROTECTED]> wrote: > > Do any applications make use of the private data in these CM message: > > RTU, MRA, or DREP? I'm doubtful of the RTU or DREP, but not as sure > of the MRA. > > > > Since no replies are generated in response to these messages, the CM > > does not keep them after their sends complete. However, it may need > > to resend the messages. For example, it will resend the RTU if a > > duplicate REP is received. > > > > If no applications are using the private data, I will not worry about > > storing the private data for the retransmissions at this time. > > > > - Sean > > _______________________________________________ > > openib-general mailing list > > [email protected] > > http://openib.org/mailman/listinfo/openib-general > > > > To unsubscribe, please visit > > http://openib.org/mailman/listinfo/openib-general > > > _______________________________________________ > openib-general mailing list > [email protected] > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit > http://openib.org/mailman/listinfo/openib-general > _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
