Socket.Receive 메서드의 SocketFlags.Peek 동작을 이용해 소켓 연결 유무를 확인?
다음과 같은 글을 보게 되었습니다.
C#: How to determine if a TCPClient has been disconnected
; https://social.msdn.microsoft.com/Forums/en-US/c857cad5-2eb6-4b6c-b0b5-7f4ce320c5cd/c-how-to-determine-if-a-tcpclient-has-been-disconnected?forum=netfxnetcom
위의 글에 보면, TcpClient 객체의 소켓 연결이 끊겼는지에 대한 판단으로 다음과 같은 답변이 6개의 추천을 받고 있는데요.
// https://stackoverflow.com/questions/101708/tcpclient-connected-returns-true-yet-client-is-not-connected-what-can-i-use-ins
// Detect if client disconnected
if( tcp.Client.Poll( 0, SelectMode.SelectRead ) )
{
byte[] buff = new byte[1];
if( tcp.Client.Receive( buff, SocketFlags.Peek ) == 0 )
{
// Client disconnected
bClosed = true;
}
}
Win32 API 개발자라면 Message Loop의
GetMessage/
PeekMessage Win32 API를 연상하면서 "Peek" 인자를 주면 소켓의 수신 버퍼에 데이터가 있는지만 확인하고 바로 반환하는 거라고 오해할 수 있는데요. SocketFlags.Peek 인자를 주었어도 Receive 메서드는 blocking 함수라는 것을 잊으면 안됩니다.
이로 인해, 만약에 여러분들의 UI 스레드와 같은 식의 주요 작업자 스레드에서 소켓이 연결되었는지 확인하기 위해 저런 식으로 Receive 메서드를 호출했다가는 자칫 무한 대기(hang)로 빠질 수 있습니다.
일단, 주의사항은 그렇긴 하지만 위에서 소개한 코드가 그런대로 잘 동작하긴 합니다. 한번 동작을 분석해 볼까요? ^^
Poll 메서드에 SelectMode.SelectRead 옵션을 주는 경우, 다음과 같이 3가지 상황에서 true를 반환하게 됩니다.
1) true if Listen has been called and a connection is pending;
2) true if data is available for reading;
3) true if the connection has been closed, reset, or terminated;
otherwise, returns false.
일단, 클라이언트 측 소켓이라고 한정하면 1번은 해당 사항이 없습니다. 따라서 "데이터 수신이 되었거나, 연결이 끊어졌으면 true를 반환한다"라고 범위를 좁힐 수 있습니다.
이에 따라 서버가 Close를 호출하면, 클라이언트 측에서는 Poll 메서드가 true를 반환하게 됩니다. 그리고 Receive(..., Peek)는 0을 반환하게 되고 의도했던 것처럼 연결이 끊겼음을 알아낼 수 있습니다. 하지만, 헛점도 있습니다. 예를 들어, 서버가 다음과 같이 Send를 한 다음 바로 연결을 종료하고,
while (true)
{
TcpClient clientSocket = serverSock.AcceptTcpClient();
Console.WriteLine("accepted");
byte[] buf = new byte[4];
clientSocket.Client.Send(buf);
clientSocket.Close();
Thread.Sleep(Timeout.Infinite);
continue;
}
이 상태에서 클라이언트가 Receive 없이 IsConnected를 호출하게 되면 연결은 계속 맺어져 있다고 나옵니다.
private static void ClientFunc(object obj)
{
TcpClient clientSocket = new TcpClient();
string[] args = Environment.GetCommandLineArgs();
string serverAddress = "localhost";
clientSocket.Connect(serverAddress, 5000);
if (serverAddress == "localhost")
{
Thread.Sleep(1000);
}
bool loop = true;
while (loop)
{
loop = IsConnected(clientSocket); // True 반환
Console.WriteLine(loop);
Thread.Sleep(1000);
}
clientSocket.Close();
}
이때 netstate를 실행해 소켓의 상태를 보면,
c:>netstat -ano |findstr "5000"
TCP 0.0.0.0:5000 0.0.0.0:0 LISTENING 10380
TCP 127.0.0.1:5000 127.0.0.1:57373 FIN_WAIT_2 10380
TCP 127.0.0.1:57373 127.0.0.1:5000 CLOSE_WAIT 10380
서버 소켓은 close를 호출했기 때문에 FIN_WAIT_2 상태로 빠졌고, 클라이언트는 CLOSE_WAIT으로 진입했습니다. (참조:
"코드로 재현하는 소켓 상태(FIN_WAIT1, FIN_WAIT2, TIME_WAIT, CLOSE_WAIT, LAST_WAIT)")
이 외에, 다중 스레드에서 IsConnected 메서드를 호출하는 경우 무한 대기에 빠질 수 있는 조건이 있습니다. 예를 들어, 서버가 Send만 하고 Close를 호출하지 않은 상황에서 클라이언트 측 소켓이 Poll(..., SelectRead)를 호출하면 true를 반환하게 됩니다. 따라서 if 문 내부로 진입하게 되는데, 이때 스레드 스위칭이 발생해서 다른 스레드에서 동일한 소켓 자원으로 Receive를 호출하여 수신 버퍼의 데이터를 모두 읽어간다면 어떻게 될까요? 당연히! 다시 Poll 메서드를 호출한 스레드가 스케쥴링되는 경우 Receive(..., Peek)라고 호출하면 무한 대기(hang)에 빠지게 됩니다. 물론, 이런 오류는 쉽게 재현되지 않기 때문에 다중 스레드에서 소켓을 사용하는 경우 IsConnected(...)처럼 사용했다가는 머리를 쥐어뜯는 상황으로 이어질 수 있습니다.
굳이, 재현을 위해 특별하게 다음과 같이 코드를 만들어 볼 수도 있습니다.
using System;
using System.Net;
using System.Net.Sockets;
using System.Threading;
class Program
{
static void Main(string[] args)
{
Thread serverThread = new Thread(serverFunc);
serverThread.IsBackground = true;
serverThread.Start();
Console.ReadLine();
}
private static void serverFunc(object obj)
{
TcpListener serverSock = new TcpListener(IPAddress.Any, 5000);
serverSock.Start(5);
{
Thread clientThread = new Thread(ClientFunc);
clientThread.IsBackground = true;
clientThread.Start();
}
while (true)
{
TcpClient clientSocket = serverSock.AcceptTcpClient();
Console.WriteLine("accepted");
byte[] buf = new byte[4];
clientSocket.Client.Send(buf);
Thread.Sleep(Timeout.Infinite);
continue;
}
}
private static void ClientFunc(object obj)
{
TcpClient clientSocket = new TcpClient();
string[] args = Environment.GetCommandLineArgs();
string serverAddress = "localhost";
clientSocket.Connect(serverAddress, 5000);
if (serverAddress == "localhost")
{
Thread.Sleep(1000);
}
bool loop = true;
EventWaitHandle ewh = new EventWaitHandle(false, EventResetMode.ManualReset);
while (loop)
{
ThreadPool.QueueUserWorkItem(
(arg) =>
{
Thread.Sleep(1000);
byte[] buf = new byte[1024];
int readLen = clientSocket.Client.Receive(buf);
Console.WriteLine("Client.Receive: " + readLen);
((EventWaitHandle)(arg)).Set();
}
, ewh);
loop = IsConnected(ewh, clientSocket);
Console.WriteLine(loop);
Thread.Sleep(1000);
}
clientSocket.Close();
}
public static bool IsConnected(EventWaitHandle ewh, TcpClient clientSocket)
{
try
{
if (clientSocket.Client.Poll(0, SelectMode.SelectRead))
{
ewh.WaitOne();
byte[] buff = new byte[1];
if (clientSocket.Client.Receive(buff, SocketFlags.Peek) == 0) // 무한 대기(hang) 현상 발생
{
return false;
}
}
}
catch
{
}
return true;
}
}
위의 코드를 실행하면 Poll 메서드는 수신 버퍼에 데이터가 있으므로 true를 반환해서 if 문 내로 진입했다가 WaitOne으로 시뮬레이션한 스레드 스위칭이 발생한 후 다른 스레드에서 Receive를 하는 바람에 이후 Receive(..., Peek)에서 무한 대기 현상이 발생하는 것을 확인할 수 있습니다.
아쉬운 대로, 일단 무한 대기 현상만 수정해 보겠습니다. 이를 위해서는 Receive를 호출해서는 안되고 실제로 '수신 버퍼'에 데이터가 있는지에 대한 체크만 해주는 함수를 호출해야 합니다. 이를 위해 IOControl 메서드를 쓸 수 있습니다.
public static bool IsConnected(EventWaitHandle ewh, TcpClient clientSocket)
{
try
{
if (clientSocket.Client.Poll(0, SelectMode.SelectRead))
{
ewh.WaitOne();
byte[] buff = new byte[1];
// DataToRead == 0x4004667f (0n1074030207)
byte[] dataToRead = new byte[4];
clientSocket.Client.IOControl(IOControlCode.DataToRead, null, dataToRead);
if (BitConverter.ToInt32(dataToRead, 0) == 0)
{
return false;
}
//if (clientSocket.Client.Receive(buff, SocketFlags.Peek) == 0)
//{
// return false;
//}
}
}
catch
{
}
return true;
}
또는, 해당 IOControl 호출과 동일한 역할을 수행하는
Socket.Available 속성을 조사하면 됩니다.
public static bool IsConnected(EventWaitHandle ewh, TcpClient clientSocket)
{
try
{
if (clientSocket.Client.Poll(0, SelectMode.SelectRead))
{
ewh.WaitOne();
byte[] buff = new byte[1];
return clientSocket.Client.Available != 0;
}
}
catch
{
}
return true;
}
비록 이것으로 무한 대기(hang) 현상을 막을 수는 있지만, 아쉽게도 저 상황에서는 연결이 끊겼다는 잘못된 판단을 내리게 됩니다. 결국, 이런 방식으로는 소켓 연결이 끊겼는지에 대한 올바른 함수를 만들 수는 없습니다.
(
첨부한 파일은 이 글의 예제 코드를 포함합니다.)
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]