Abnormal interface calls simple, multi-platform support RTSP-Server client components EasyRTSPServer dropped cause some obstruction solutions to problems

RTSP protocol is a streaming protocol, can realize play audio and video streaming of live and on-demand form. RTSP protocol defines a variety of servers - the interaction between the client interface, there are OPTIONS, DESCRIBE, SETUP, PLAY, TEARDOWN, RECORD, ANNOUNCE. Much has been written for the RTSP protocol on the network, I'm not ready to introduce too much here. RTSP does not include the transmission of specific data, this function is generally realized by RTP and RTCP protocol, and may be performed by two kinds of the underlying TCP or UDP transport mode.

The figure is a typical RTSP live process server - client primary interaction process:

EasyRTSPServer is a stable, efficient, reliable, multi-platform support RTSP-Server component, the interface is very simple and sophisticated call today to share with you about EasyRTSPServer client dropped the abnormal part of the problem leading to obstruction of

Ask a question:

EasyRTSPServer in the Linux environment will be dropped because the client is abnormal, even now resulting in some channels can not be accessed.

analyse problem:

Analysis server could have been CLOSE_WAIT in the debugging process, but found a blockage, a careful analysis of the events live555 call flow, we found that as long as the data is received from the client, it will execute GenericMediaServer :: ClientSession :: noteLiveness (), the function deletes the last timeout in the event, and then create a timeout event into the scheduler queue, and the client suddenly dropped, normally would call the timeout task, delete ClientSession in this task, in the case of a large number of client connections (128) suddenly dropped, there is a chance there will be blocked, resulting in no call to the timeout event, which led socket can not be released.

The destruction of a timeout on the task of creating a new task timeout

void GenericMediaServer::ClientSession::noteLiveness() {

  if (fOurServerMediaSession != NULL) fOurServerMediaSession->noteLiveness();

  if (fOurServer.fReclamationSeconds > 0) {
		pEnvironment->taskScheduler().rescheduleDelayedTask(fLivenessCheckTask,
							  fOurServer.fReclamationSeconds*1000000,
							  (TaskFunc*)livenessTimeoutTask, this);
}
}

Timeout task to achieve the following

void GenericMediaServer::ClientSession::livenessTimeoutTask(ClientSession* clientSession) {
	delete clientSession;
}

Plus the N number of print logs final analysis epoll detected socket there is an event, and calls the appropriate handler, in this function, call recvfrom caused by obstruction ... and suddenly, quickly found what SO_RCVTIMEO, sure enough, in live555 all code, not to search for that keyword.

Solve the problem:

After you create a socket, set the timeout to receive data.

#if defined(__WIN32__) || defined(_WIN32)
    DWORD msto = (DWORD)500;
    setsockopt(newSocket, SOL_SOCKET, SO_SNDTIMEO, (char *)&msto, sizeof(msto) );
    setsockopt(newSocket, SOL_SOCKET, SO_RCVTIMEO, (char *)&msto, sizeof(msto) );
#else
    struct timeval tv;
    tv.tv_sec = 0;
    tv.tv_usec = 500*1000;
    setsockopt(newSocket, SOL_SOCKET, SO_SNDTIMEO, (char *)&tv, sizeof tv);
    
    setsockopt(newSocket, SOL_SOCKET, SO_RCVTIMEO, (char *)&tv, sizeof tv);
#endif