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.
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
