TCP/IP 통신에서, 같은 port에 접속하는 여러개의 socket/connection 의 통신 중 접속이 끊어지는 문제입니다.
질문을 간단히 쓰려 했는데, 잘 안되네요.
음... 지금 어떤 상태냐면요. network( TCP/IP ) / cpu 관련 stress test를 하기 위한 거구요.
기존 프로그램에서 자꾸 connection이 끊어져서, 그걸 테스트 하려는 겁니다.
테스트하려는 server 프로그램이 있어서, 거기에 client 역할을 하는 프로그램을 Dummy로 만들어서 테스트를 하려고 합니다.
패킷 자체는 단순하구요( Req/Ack ) , 단순히 주고 받는 것만 계속합니다.(테스트 목적이라..)
1. server가 떠 있고.
2. client는 고정된 하나의 ip/port로 서버에 접속합니다.
3. 복수개의 접속 스트레스를 가하기 위해, 더미 쪽에서 thread로, 동일 ip/port에 대해 여러 개의 socket / connect 를 합니다.
4. 열린 socketFD 로 Client 가 Req 를 발송 / Server 가 Ack를 반송합니다.
5. 뜬금없이 부정기적으로 connection이 끊기는 현상이 발생합니다.
테스트라서 로컬에서 서버/클라이언트 띄어놓고 작업했구요, ip도 로컬(127.0.0.1) 입니다.
socket 열 때 setsockopt( SO_REUSEADDR ) 해서 port는 재사용할 수 있도록 했구요. 테스트중 netstat 해 봐도 지정한 port가 특별히 TimeOut 이나 CloseWait로 기다리지는 않습니다.
끊길때 perror로 찍어보면,
Server쪽( 기존 프로그램 )에서는 read() 로 Req를 기다려도 넘어오는 패킷이 없어서 TimeOut 나구요 (서버쪽에서 socket 열릴 때 timeOut을 3초로 설정해 놨습니다.)
Client쪽에서는 Write()로 Req를 보내려 해도 Bad file Descriptor 를 리턴하고 packet을 쓰지 못합니다. 아마 connection이 끊어졌으니까 Bad file Descriptor가 나오는 거라고 생각됩니다만..
Server / Client 에서 특별히 시간 지연( sleep() 이라던가.. ) 을 일으키는 부분은 없구요.
위의 상황이 상당히 부정기적으로 발생하는 게,
11. 어떤 때는 단 한 번만 Req/Ack교환 성공 후에 5. 가 발생하기도 하고
12. 어떤 때는 끊김없이 Req/Ack교환을 100회 이상 성공하기도 합니다.
13. 또한, 맨첨에 Thread 로 만들어서 같은 port에 대해 복수개의 connect를 물리도록 했는데요. 이게 너무 잘 끊어져서 ( 원래 하루종일 접속 유지해야 하는 건데요 )
14. 혹시나 하고 함수에서 순차적으로 복수개의 connect를 한 후, 각 socketFD에 대해 루프로 돌아가면서 한번씩 Req/Ack 를 주고받도록 Dummy를 만들었더니 이건 또 끊김없이 잘 됩니다.
15. 에러 발생 비율은 일정하지 않습니다.
혹시 비슷한 경험을 하셨거나, 좋은 의견 있으시면 답변 부탁드립니다.
일단은 14. 때문에 [thread]쪽 소스에 버그가 있지 않을까..생각됩니다만, 더미용으로 만든거라 워낙 구조가 단순해서, 버그 날 만한 곳이 별로 보이지 않습니다.(봐도 안보이구요.)
그럼, 좋은 의견 있으시면 덧글 부탁드리구요. 즐거운 추석 되시기 바랍니다.
흠...
Bad file descriptor가 나온다면 프로그램 로직이 엉겨서 소켓번호를 잘 못 주었을 가능성이 높습니다. 만약 연결이 끊어졌다면 Econnreset과 같은 다른 errno가 나와야 합니다. 프로그램을 다시 한번 점검해 보시는 수 밖에 없을 듯 합니다.
답변 감사합니다.
단순히 connection 이 끊어져서 bad file descriptor 가 나왔을거라고 생각했습니다. 에러일 거라고는 생각 안 해 봤구요.
전체적으로 다시 한 번 검토해 보겠습니다. 답변 감사드립니다.
행복은 희생없이는 얻을 수 없는 것인가?
시대는 불행없이는 넘을 수 없는 것인가?
음..
설명이 조금 불분명한 부분이 있는듯 하네요..;;
server 에서 timeout 났다면, 십중팔구 client 가 데이터를 보내지 못했다는 의미일텐데..;;
client 가 multi-thread 로 write 를 경쟁하고 있다면..굶어 죽는애가 생길 수도 있습니다...
local socket close 이후에 read/write 를 호출하면 EBADF 가 떨어지는 걸로 알고 있는데..
socket fd 관리하고 read/write 하고 분리되어 있는지도 확인되어야 할 듯 하구요..
(fd close 이후에 명시적으로 -1 로 세팅해주는 습관을 들이시면, 문제 발생시 힌트가 될 수도 있습니다)
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Ｍｉｚｚ 』
Linux에서 Stress
Linux에서 Stress Test에서 connection error가 발생할 수 있는 경우가 있습니다. 위의 문제가 이 경우에 해당하는지는 모르겠습니다.
원인 중의 하나는 Connection이 Close되면 TIME_WAIT 상태가 됩니다. 문제는 FD가 65000개인데 INIT상태로 변경된 FD가 없기 때문에 더 이상 Connection을 맺을 수 없는 경우가 발생합니다. 특히 초당 수천에서 수만건만 발생해도 이런 문제는 금방 발생합니다.
리눅스라면 Network에서 TIME_WAIT 등의 설정을 변경해주세요. 네트웍 프로그래밍은 오랫만이라 제가 세팅하는 방법이 지금 기억이 안나네요.
댓글 달기