On 18 Sep 2014, at 16:21, Jamal Hadi Salim <jhs@xxxxxxxxxxxx> wrote: > On 09/18/14 09:45, Vlad Yasevich wrote: >> On 09/18/2014 09:35 AM, Jamal Hadi Salim wrote: > >>> Should i not get EINPROGRESS everytime the associate fails? >> >> Yes, but at times it was actually processing the abort before the associate due to >> locking semantics. Try putting increasing the rtt of the loopback device with netem. >> You'll then start seeing EINPROGRESS :) >> > > Ok. In my use case the rtt is small - so likely why i didnt see it. > > Another thought; (and i am not sure how to justify this since > there is no way to distinguish between async sctp events and > real data in terms of socket buffer usage) is it possible to > return me a failure immediately to the connect() if the recvmsg > buffer is used up by events I am not processing? > Sure, you could say it is the user's responsibility not to do > stoopid things;-> but this will make the interface more usable. > It would be nice to just slice the socket buffer so only a max > of the space is used for events as well. I would claim that it is > ok for some of these events not to even make it to the user. Delivery of notifications is reliable. In case the buffer is full, you'll get a final SCTP_NOTIFICATIONS_STOPPED_EVENT and the kernel unsubscribes the notifications. Best regards Michael > > >> There have been patches to tie it to netstat, but since each distro has it's own >> netstat some didn't pick it up (I think RHEL has it, not sure about Fedora or Debian). >> I'll see what I can do about add ss support. >> >> If you roll your own, you might be able to find netstat patches in the wild. I did >> them about 10 years ago :( >> > > I will dig it up. But ss would be better... > > cheers, > jamal > -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
