Posts by tonyfairbanks

  • TCP/IP socket options

    I recently ran into a problem where several remote capture stations would abort a transmission to our ConQuest server for no obvious reason. After staring at raw IP capture logs in Wireshark for way too long I noticed that Conquest was incorrectly sending a TCP RST packet when it shouldn't have. Depending on the exact timing, it would cause the remote end to abort its transmission. Further investigation led me to the following line in the DICOM specs:

    Quote from http://medical.nema.org/Dicom/2011/11_08pu.doc

    TCP Transport Connections shall be closed using the “don't linger” option.


    In the socket.cxx file in Conquest's source, Linger is specifically enabled in three locations. Once I disabled it our capture stations stopped having the transmission problems. Why Linger is enabled, which seems to be against the DICOM specs? It really seems like it shouldn't be, and in my case can't be for transfers to work correctly.


    Some further discussion of SO_LINGER can be found here: http://stackoverflow.com/quest…er-zero-when-its-required. Specifically, this is exactly what I was seeing:

    Quote

    Again, according to "UNIX Network Programming" third edition page 202-203, setting SO_LINGER with timeout 0 prior to calling close() will cause the normal termination sequence not to be initiated.


    Instead, the peer setting this option and calling close() will send a RST (connection reset) which indicates an error condition and this is how it will be perceived at the other end. You will typically see errors like "Connection reset by peer".


    Therefore, in the normal situation it is a really bad idea to set SO_LINGER with timeout 0 prior to calling close() – from now on called abortive close – in a server application.


    For reference, I'm running Conquest 1.4.16k on RHEL 6.3 x86_64.