> No, I don't think "application crashed" makes sense as an element of wire > protocol. > I think an optional logging of errors in kernel CM would be a much better > solution. I know I had to add some printks it each time I was debugging SDP.
The "application crashed" scenario is what high-lighted the issue. The problem is that the CM must provide a reject reason. Which reject reason do you use? My suggestion was for a reject reason of other/unknown/none given (pick one). > 2. Another objection is that this feature seems to invite misuse where > applications > will use REJ reason as a hint on whether remote side crashed. But REJ could be > lost. Wouldn't this confuse the remote side? Currently, the CM issues the reject using "consumer defined", since nothing else maps any better under this condition. But the reject isn't consumer defined... By doing this, an application that expects specific private data in the reject message won't find it, which is just as likely to confuse the remote side. This is why I think an unknown/unspecified reject reason is needed. How an application interprets a reject with 'unknown' reason is up to the application, but I do think this is better than the application trying to guess whether 'consumer defined' really does mean consumer defined. - Sean _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
