On 19 Sep 2014, at 13:27, Jamal Hadi Salim <jhs@xxxxxxxxxxxx> wrote: > > On 09/19/14 06:53, Michael Tuexen wrote: > >> 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. > > I agree with you on the motivation and i would have written the code > differently if i was influenced by the above thinking. > What do you think of events blocking other data messages? Would it > make sense to allow partitioning the socket buffer? I don't think so. However, events should be taken into account when computing how much space you have free in a socket buffer. Best regards Michael > > Note:the intent here is to do N client connects (on N different sockets) > and that requires non-blocking parallel approach if you want to reduce > latency. I could be more bold and do recvmsg on writeability but the > state machine is a lot simpler with continous connect. > TCP (on Linux at least) works fine. > I am hoping after Vlad's fix this would maintain that. > currently each connect returns "in progress" and as long as > i dont subscribe for events no socket buffer is being used. > > 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
