On 19 Sep 2014, at 12:38, Jamal Hadi Salim <jhs@xxxxxxxxxxxx> wrote: > On 09/18/14 15:26, Vlad Yasevich wrote: >> On 09/18/2014 10:21 AM, Jamal Hadi Salim wrote: > [..] >> As Michael pointed out, we can't do that. >> > > So while i agree with the principle Michael described: > does reliability make any sense in the case where the previous event > is obsoleted by current event? There is no new information. You just > accumulated a million events for one socket all saying "the > connect failed". I wouldn't say its is obsoleted. It just tells you that a millions of connection attempts failed. They are different attempts... I would write the code in a way that I initiate a connection attempt and wait for the response: Either it is successful or it failed. In case of failure you can decide if you want to give up, wait for some time and retry or retry immediately. To be able to do this, it is important that you can rely on getting either a notification that the association is up or that it couldn't start. Doing it this way also makes sure that you consume the notifications you subscribed to. Best regards Michael > > I think it is a reasonable default policy. > My main concern - and i cannot claim i have ever run into this in > practise - is the case where events take over all the socket > buffers at the expense of data. > > >>> 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. >> > > Why /proc based? ss does direct netlink. > > 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
