2010/10/23 Jen Chitty <jenchi...@vtech.ca>: > We are trying to track down an intermittent failure in the Sofia SIP stack > where we appear to be getting an EPERM error back from some POSIX API call > or another on a powerpc Linux 2.6.23. This error is somehow triggering the > stack to report an ACK timeout, even though no timer has expired. Does this > sound familiar to anyone? > > Anyway, I came across a line of code in tport_type_udp.c that I found > somewhat alarming: > > su_soerror(self->tp_socket); /* XXX - we *still* have a race condition > */ > > Does anyone know what race condition this is referring to?
When network reports an error with ICMP message, the kernel stores the error in the socket and wakes up the application with special error event. Application can ask for the error code using su_soerror() (getsockopt system call with SO_ERROR argument) but if it does not, next time application tries to read or write from the socket, the error is reported to it. If Sofia SIP application talks with two other SIP instances, say A and B, and it sends a request to A, but A is unreachable and A's router reports back an error with ICMP, send to *B* may fail if the ICMP packet from A is received before call to su_vsend() (sendmsg() system call). The above code clears the error just before call to su_vsend. Doing so reduces the size of the window where an unrelated ICMP can trigger failure when sending but it does not remove it entirely. -- Pekka.Pessi mail at nokia.com ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Sofia-sip-devel mailing list Sofia-sip-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sofia-sip-devel
