A udp socket in the middle of a sock.receive() is closed (sock.close()
is called) and an IOException is raised after about 6 minutes.
Here's the code snippet :
try {
receiving = true;
socket.receive(packet);
receiving = false;
}
catch (SocketTimeoutException ste) {
receiving = false;
throw ste;
}
catch (IOException ioe) {
receiving = false;
socket = null;
break;
}
The udp socket is receiving rtp data and socket.close() is called from
another thread. By the time socket.close() is called, the rtp sender may have stopped sending the data or even
closed the rtp socket (Cu can not control what is done on the sender
side).
In any case, calling socket.close() should raise an IOException
immediately. But we're getting the exception close to 6 minutes after
the call to close(). Suggesting the socket.receive() was stuck for
some reason.
This scenario seems to be acceptible with a TCP socket where sock.close() still
keeps the socket open for a possible receive call [TCP FIN means 'done
sending' not receiving]. But with UDP, this seems to be a problem.
###@###.### 2004-12-07 06:52:58 GMT
is called) and an IOException is raised after about 6 minutes.
Here's the code snippet :
try {
receiving = true;
socket.receive(packet);
receiving = false;
}
catch (SocketTimeoutException ste) {
receiving = false;
throw ste;
}
catch (IOException ioe) {
receiving = false;
socket = null;
break;
}
The udp socket is receiving rtp data and socket.close() is called from
another thread. By the time socket.close() is called, the rtp sender may have stopped sending the data or even
closed the rtp socket (Cu can not control what is done on the sender
side).
In any case, calling socket.close() should raise an IOException
immediately. But we're getting the exception close to 6 minutes after
the call to close(). Suggesting the socket.receive() was stuck for
some reason.
This scenario seems to be acceptible with a TCP socket where sock.close() still
keeps the socket open for a possible receive call [TCP FIN means 'done
sending' not receiving]. But with UDP, this seems to be a problem.
###@###.### 2004-12-07 06:52:58 GMT