On 09/18/2014 10:21 AM, Jamal Hadi Salim 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? I hesitate to do this as this could break existing applications. Also, this would only be applicable to 1-1 sockets as 1-many socket may have multiple outstanding connection attempts, so we would still have memory issues here. > 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. > As Michael pointed out, we can't do that. > >> 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... I'll see what I can cobble together. Problem is that it would have to be /proc based, but that's better then nothing. -vlad > > 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
