> On 7 Jun 2020, at 14:47, Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx> wrote: > >> On 7. Jun 2020, at 14:18, Andreas Fink <afink@xxxxxxxxxxxxx> wrote: >> >> Hello folks, >> >> I run into a strange issue with SCTP under Linux and I'm not sure whats the right approach to fix this. >> >> I have a listener thread which listens on a port for multiple inbound connections >> I have a sender thread which sends packets to peers by using the same socket and doing a sctp_sendv call. >> Sockets are always in non blocking mode. > So a single SOCK_SEQPACKET socket for sending and receiving, right? correct >> >> When the remote side gets stopped (process killed), the sctp_sendv starts returning 0 and errno is set to EAGAIN and we constantly retry. > When it returns 0, you can't look at errno. errno is only set to a correct value, if -1 is returned. I actually check if return value is > 0. So probably -1 applies here. Returning 0 doesnt make any sense anyway. > > If you killed the peer, I would assume that there is an SCTP message containing an > ABORT chunk in the wire. Is that true? I can not currently verify that. But we have seen this happening when the remote application (which uses the same mechanism) got killed or has crashed. So the operating system's sctp driver should have sent ABORT I believe. We noticed that when the remote application restarts, it can not reestablish the connection somehow, probably because the main application is still busy looping sending old data in the queue. > If that is true, you could subscribe to > SCTP_ASSOC_CHANGE notification, which should tell you. I am subscribed to SCTP_ASSOC_CHANGE but I didnt catch anything there. (or I catched it in the receiver thread and the sender thread is not checking the new status in its tight sending loop) My question is, what is the exact meaning of EAGAIN here? Does it mean that the send buffer is full? Why am I not getting a simple error because the specified assoc is down?
