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