현재 위치

홈 ›› Forums ›› 공부 ›› 프로그래밍 QnA

Linux에서는 TCP_NODELAY이 없나요?

miso의 이미지
글쓴이: miso / 작성시간: 금, 2003/01/10 - 6:52오후

/* disable nagle algorithm*/
if (setsockopt(so, IPPROTO_TCP, TCP_NODELAY, (char*)&tcp, sizeof(int))) {
printf("nagle algorithm error\n");
return FALSE;
}
에서 다음과 같은 에러가 나타나는 데요....
이유가 뭔지....

`TCP_NODELAY' undeclared (first use this function)
(Each undeclared identifier is reported only once
for each function it appears in.)

저는 unix가 아니라 linux거든요?
이것을 쓰려고 하는 이유는
socket 통신을 하는데 netstat 로 통신 상태를 확인하면...
TIME_WAIT 상태가 너무 오래 있거든요...
이것을 줄일 수 있는 방법이 없을까요?

LIINGER 옵션을 쓰는데도 time_wait 시간이 너무 긴것 같아요..
그래서 TCP_NODELAY을 쓰려고 하는데...
안돼네요...
TCP_NODELAY 옵션을 써도 해결할 수 없나요?

Forums: 
프로그래밍 QnA
arimae의 이미지

글쓴이: arimae / 작성시간: 금, 2003/01/10 - 7:08오후

Quote:
/* disable nagle algorithm*/
if (setsockopt(so, IPPROTO_TCP, TCP_NODELAY, (char*)&tcp, sizeof(int))) {
printf("nagle algorithm error\n");
return FALSE;
}
에서 다음과 같은 에러가 나타나는 데요....
이유가 뭔지....

`TCP_NODELAY' undeclared (first use this function)
(Each undeclared identifier is reported only once
for each function it appears in.)

#include <linux/socket.h>
#include <netinet/tcp.h>

위의 두개 중에 하나를 include 했나 확인해보시길 바랍니다. TCP_NODELAY는 위의 두 헤더 파일에
define 되어 있습니다.

Quote:
저는 unix가 아니라 linux거든요?
이것을 쓰려고 하는 이유는
socket 통신을 하는데 netstat 로 통신 상태를 확인하면...
TIME_WAIT 상태가 너무 오래 있거든요...
이것을 줄일 수 있는 방법이 없을까요?

다음의 코드를 사용해 보시길 바랍니다.

int optval = 1;

setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof (optval));

이러면 소켓이 닫힌후 바로 재사용할 수 있을것입니다.

Dream, Passion and Challenge..

miso의 이미지

글쓴이: miso / 작성시간: 토, 2003/01/11 - 11:06오전

님께서 알려주신데로 하니...

`TCP_NODELAY' undeclared (first use this function)
(Each undeclared identifier is reported only once
for each function it appears in.)

이 에러는 안나요....
그런데...
TIME_WAIT 시간이 줄어들질 안네요...

SO_LINGER 옵션을 아래와 같이 사용해도....

lin.l_onoff = 1;
lin.l_linger = 10;
if (setsockopt(so, SOL_SOCKET, SO_LINGER, (char*)&lin, sizeof(lin)))
printf("socket set linger error\n");

packet은 잘 주고 받는데...

TIME_WAIT 시간을 재보니 35초에서 45초는 걸리는 것같아요...
만약에 프로그래밍에서 해결할 수 없다면...
시스템에서 따로 설정해져야 하는 것이 있나요?
아님 프로그램 코딩 안에서 해결할 수가 있나요?...

제가 지금 하는 작업이 제가 짠 자바 서버를 그대로 LINUX에서 C++ 서버로 다시 짜고 있거든요...
그런데...
자바 서버로 돌리면.. TIME_WAIT 시간이 없이
netstat로 확인을 하면
ESTABLISHED 값 밖에 없거든요...
그러니까 close하면 바로 TIME_WAIT 없이 바로 CLOSE 된다는 이야기인것 같은데....

자바 서버를 돌리고 있는 컴퓨터랑.. 지금 제가 C로 만들고 있는 컴퓨터랑
틀리거든요...
그런데...
같은 리눅스인데.... 이렇게 다를 수 가있나요...
자바 서버가 돌고 있는 컴퓨터를 제가 설치한 것이 아니라서....
혹시 설치 할때 따로 옵션을 줘야하는 것이 아닌가... 해서요...
만약에 따로 옵션을 줘야 한다면.. 그것이 무엇인지....
또 어떻게 옵션을 줘야 하는지...
제가 리눅스는 완전 초보라서요.. C만 쪼금할 줄알지...
그래서 그런데.. 좀 자세히 좀 설명 좀 주세요... ^^;;

그럼 좋은 주말 보내세요....

*^^*

arimae의 이미지

글쓴이: arimae / 작성시간: 토, 2003/01/11 - 12:13오후

위에서 TIME_WAIT 없애는 코드를 알려드렸는데..
TCP_NODELAY는 TIME_WAIT하고는 상관없습니다. 단지 Flow Control 과 연관된 부분이죠..

TIME_WAIT 를 없애려면 위에서 적은 대로 setsockopt를 호출하면 됩니다.

int optval = 1; 

setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof (optval));

설치할때 따로 옵션을 주지 않고 위의 함수를 호출하면 소켓이 닫히자 마자 곧바로 사용할 수 있게 해줍니다.

Dream, Passion and Challenge..

miso의 이미지

글쓴이: miso / 작성시간: 월, 2003/01/13 - 10:14오전

님께서 말씀하신....

int optval = 1;

setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof (optval));

이코드를 사용하고 있거든요.....
그런데...
이것은 소켓을 재사용하겠다는 것 아닌가요...
netstat로 소켓 번호를 보면 다 다른 번호가 뜨는데요..
그러다가 한 35초에서 45초가 지나면 사라지고요..
계속해서 다른 소켓 번호가 뜹니다.

제가 테스트를 하고 있는 중인데...
클라이언트를 while 문을 돌려서 계속 접속시키고 있습니다...
그런데...
netstat로 확인을 하면... TIME_WAIT 가 계속 늘어나서요.....

지금 서비스하고 있는 자바 서버에서는 그런 현상이 없거든요...
자바와 C의 차이인지...
아님... 코드상에서 해결할 수있는것인지.. 아님.. 시스템쪽으로 해결 방법이 있는지.. 아님.. C로 서버를 짜면 원래 그런 것인지... 아님.. 이런 현상이 정상인지...

제가 unix 특히 linux에 대해서는 완전 초보 이거든요...
이것은 빨이 해결을 해야 하는데.. 일주일 넘게 이러고 있는니...
저의 한계를 절실히 느끼고 있습니다..
고수님들의 많은 조언 부탁드립니다..... ^^;;;

*^^*

arimae의 이미지

글쓴이: arimae / 작성시간: 월, 2003/01/13 - 10:56오전

TIME_WAIT 상태를 없애려는 이유가 무엇때문인지 궁금하군요.
위에 제가 드린 코드는 서버가 종료된후 일정시간 동안 TIME_WAIT 상태 때문에 해당 포트로 bind 할 수 없는 경우가
생기는데 이것을 강제적으로 사용할 수 있게 해주는 코드입니다.

TIME_WAIT 상태는 TCP의 기본적인 구현입니다.
TCP의 state trasition diagram을 살펴보면 Active Close의 마지막 상태가 TIME_WAIT 상태입니다.
이 시간은 보통 2 MSL(Maximum Segment Life) 정도 이고, MSL의 시간은 시스템 마다 다릅니다.(RFC1122에는 2분이라고 적혀있습니다.)
하여튼 리눅스 소켓이든, 윈도우 소켓이든 이 TIME_WAIT 상태는 원래 존재하는 것입니다.

지금 소켓 옵션을 살펴보니 TIME_WAIT 상태를 피하는 옵션이 있긴 있군요.
SO_LINGER를 사용하면 TIME_WAIT 상태를 피할수 있다고 합니다.

struct linger {
int l_onoff;
int l_linger;
}

여기서 l_onoff를 nonzero로 l_linger를 0으로 두면 TIMEWAIT 상태를 피한다고 합니다. 테스트는 하지 않았습니다.
하지만 책을 보니 SO_REUSEADDR을 사용을 권장하는 군요.
어떤 목적으로 TIME_WAIT 상태를 없애려고 하는지는 모르겠지만, 서버 프로세스가 너무 많이 실행되어 소켓 Descriptor가 다차서
종료된 소켓은 바로 바로 소멸되게 하는것이 아니라면 그냥 놔두시는 것이 좋을것 같습니다.

Dream, Passion and Challenge..

낙엽의 이미지

글쓴이: 낙엽 / 작성시간: 월, 2003/01/13 - 11:33오전

setsockopt에서 option을 주더라도, TIME_WAIT는 줄어들지 않습니다.

시스템에 디폴트로 설정되어 있는 time_wait을 확인하세요.

#ndd -get /dev/tcp tcp_time_wait_interval

milisecond로 나옵니다. 다시 설정해 주려면,

ndd -set /dev/tcp tcp_time_wait_interval 값(예: 10000(10초))

유닉스에서는 위와 같은데 아마 리눅스도 같을겁니다. 확인해 보시길..

아참 그리고 저는 미지 낙엽님이 아니고 kldp에서는 야반 아뒤씁니다.

즐프~ :wink:

miso의 이미지

글쓴이: miso / 작성시간: 월, 2003/01/13 - 11:52오전

TIME_WAIT 상태를 없애려고 하는 이유는....
앞에서도 말씀드렸드시.. JAVA 서버에서는 그런 현상이 전혀 없습니다....
ESTABLISHED 상태에서 클라이언트가 접속을 끊으면 서버에서 생성된
소켓이 TIME_WAIT 상태 없이 사라집니다...
그런데.. C 로 만든 서버는 ESTABLISHED 상태에서 35초에서 45초간
TIME_WAIT 상태에 머물러 있습니다...

서버를 돌리고.. 테스트를 시작하면... 좀 시간이 흐른뒤..

서버로 telnet으로 다른 사용자가 접속을 한다든지.... 이메일을 확인을 하려면... 느려졌다가..좀 후에는 아예 접속이 안되요..

이것 때문인지.. 아님 다른 원인이 있서서인지... 는 잘 모르겠지만...
원인을 밝히기 위해서...

같이 작업을 하는 사람이 이것(time_wait) 때문에 나타나는 현상이라고...
우겨서요...
java 서버에서는 없었던 현상이 C 서버에서 발생하니까...
그리고 꼭 C로 서버를 짜야해서..

저도 위분이나 의뢰처에 설명을 할 수있어야 하는데...
정확한 이유가 제가 코드를 잘 못 짜서 그런것인지.. 아님 시스템 문제인지... 아님.. 원래 그런 것인지.. 설명을 할 수 있어야 겠기에...
또 이것 저것 설명하는 니 차라리.. java 서버에서와 같은 상태를 만드는 것이 좋겠다고 생각이 들어서.. 이왕이면.. 같게 할 수 없을까 해서...
이렇게 도움을 청합니다...

그러고 님께서 말씀하신...
SO_LINGER 옵션에서.. l_linger를 0으로 줬더니..
한번은 packet을 주고 받는데.. 그다음 부터는 패킷을 주고 받지 못하고
클라이언트가 죽어 버리네요...

*^^*

miso의 이미지

글쓴이: miso / 작성시간: 월, 2003/01/13 - 11:58오전

제 linux에서..
아래와 같이 하니....
# ndd
다음과 같은 말이 나오는데요...
ndd: Command not found.

ndd 명령을 사용하려면 따로 설치해야하는 프로그램이 있나요?
번거럽겠지만.... 그래도.. 아직까지 해메고 있는 불쌍한 인생을 위해서..
한번만 더.. linux 시스템에서 설정하는 방법 좀 알려주세요.. .^^;;;

*^^*

arimae의 이미지

글쓴이: arimae / 작성시간: 월, 2003/01/13 - 2:26오후

Stevens 씨가 저술한 Unix Network Programming 책의 187 페이지 SO_LINGER Socket Options 부분의
중간 쯤을 보면 다음과 같은 내용이 나오죠..

If l_onoff is nonzero and l_linger is 0, TCP aborts the connection when it is closed. 어쩌구.. This avoids TCP's TIME_WAIT state, but in doing so leaves open the possibility of another incarnation of this connection being created within 2MSL seconds.

위의 내용으로 봐서는 setsockopt에 SO_LINGER를 이용해서 TIME_WAIT 상태를 피할수 있는것이 맞습니다.

그리고 TIME_WAIT 상태 때문에 여러 이상이 발생하셨다고 하는데..
그건 저도 잘 모르겠군요. TIME_WAIT 상태는 지극히 정상적인 상태입니다.
예를 들어 지금 윈도우 에서 telnet을 실행시켜 서버에 접속한 다음 접속을 종료해 보시면,
방금 접속된 TCP 세션의 상태가 TIME_WAIT 상태로 변하게 된것을 확인할 수 있습니다.
따라서 TIME_WAIT 상태 때문에 다른 서비스가 방해가 된다는 것은 옳지 않은것 같습니다. 그것 보단
차라리 다른 부분을 확인해보시길 바랍니다. 예를 들어 클라이언트의 접속이 짧은 시간안에
많이 일어나는지의 여부를 확인해보시길 바랍니다. 한꺼번에 너무 많은 접속이 일어날 경우
(일종의 DOS 공격 상태) 그런 현상이 발생할 수 있습니다..

아래는 SO_LINGER를 이용하여 TIME_WAIT 상태가 안생기도록 설정한 프로그램입니다.
클라이언트 프로그램입니다. (혹시 서버쪽 소켓에 설정하셨는지?)
Unix Network Programming 책의 423 페이지에 나와있는 소스를 Linux에 맞게 약간 변형하였습니다.
테스트 해보니 잘 되는군요.

#include <stdio.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/inet.h>

int main(int argc, char **argv)
{
        int sockfd;
        struct linger ling;
        struct sockaddr_in servaddr;

        if (argc != 2)
        {
                fprintf(stderr, "Error\n");
                exit(1);
        }

        sockfd = socket(AF_INET, SOCK_STREAM, 0);

        bzero(&servaddr, sizeof(servaddr));
        servaddr.sin_family = AF_INET;
        servaddr.sin_port = htons(21345);
        inet_aton(argv[1], &servaddr.sin_addr);

        connect(sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr));
        ling.l_onoff = 1;
        ling.l_linger = 0;
        setsockopt(sockfd, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling));


        close(sockfd);
        return 0;
}

Dream, Passion and Challenge..

arimae의 이미지

글쓴이: arimae / 작성시간: 월, 2003/01/13 - 2:30오후

예전에 제가 TIME_WAIT 상태에 대해 정리했던 글입니다. 한번 읽어보시길 바랍니다.
Unix나 Linux 상에서 네트워크 프로그래밍을 하실때는 W.Richard Stevens가 저술한 Unix Network Programming을 참고하시면
많은 도움이 됩니다.(유닉스 네트워크 프로그래밍 서적의 바이블이죠.)

Quote:
TCP는 여러개의 State를 가질수 있습니다. 예를들어 CLOSED(연결이 닫혔을때) LISTEN(연결을 기다리고 있을때), ESTABLISHED(연결이 되었을때) 등등의 상태를 가질수 있습니다. 이중에서 TIME_WAIT라는 상태가 있는데, 이해하기 가장 어려운 부분인것 같습니다. TIME_WAIT 상태는 다음과 같은 경우에 발생합니다. 우선 Client와 Server가 TCP로 연결이 되어 있다고 가정합시다. 이때 클라이언트가 연결을 끊으려면 close함수를 호출합니다. 이 함수를 호출하면 서버에 FIN segment를 보내게 됩니다. 그러면 서버는 이 메시지를 받고 클라이언트가 접속을 끊으려고 하는 것을 알게됩니다. 따라서 서버가 CLOSE_WAIT 상태가 되면서 클라이언트에게 ack segment를 보냅니다. 즉 "네가 접속을 끊는 다는 신호를 받았다" 이런 의미입니다. 이 메시지를 받으면 클라이언트는 FIN_WAIT_2 상태가 됩니다. 이 상태에서 서버는 자신의 socket을 close하고 다시 클라이언트에게 FIN segment를 보냅니다. 즉 자신도 연결을 닫았다는 신호를 클라이언트에게 보내는 것입니다. 이 메시지를 받으면 클라이언트는 ack segment를 보내면서 TIME_WAIT 상태가 됩니다. 즉 서로간의 확인하에 완전히 연결이 끊기게 됩니다. 근데 이 상태에서 곧바로 CLOSED 상태가 되는 것이 아니라 2 MSL(maximum segment lifetime - 1분~4분) 동안 TIME_WAIT상태를 유지합니다. 왜 곧바로 CLOSED 상태가 되지 않고 일정시간 동안 TIME_WAIT 상태가 되는 것일까요?

뭔가 이상하지 않습니까? 그 이유는 다음과 같습니다. TCP는 신뢰성을 보장해 주는 프로토클 입니다.(UDP는 아니지요.) 따라서 연결시에도 신뢰성을 보장하기 위하여 Three-way handshake라는 기법을 사용하여 연결을 하고 종료시에도 위와같이 복잡한 과정을 거쳐 서로가 close된것을 확인하게 되는 것입니다. TIME_WAIT 상태도 이와같은 신뢰성 보장을 위한 한가지 방법이라고 보시면 됩니다.

Unix Network Programming에 보면 TIME_WAIT 상태가 있는 이유에 대해 다음과 같이 설명하였습니다.

1. to implement TCP's full-duplex connection termination reliably, and
2. to allow old duplicate segments to expire in the network.

흠 첫번째는 신뢰성있는 연결 종료를 위한 것이라고 쓰여있습니다. 근데 두번째는 무엇일까요?
network에 있는 duplicate segments들이 소멸시키기 위해서?? 무슨 소리인지 -_-;;
이 두가지에 대하여 자세히 설명해 보겠습니다.

먼저 첫번째에 대해서 설명하겠습니다.
이것은 말그대로 신뢰성있은 연결 종료를 위한것입니다. 다음과 같은 상황을 가정합시다. 클라이언트가 FIN_WAIT_2 상태에서 서버의 FIN segment를 받으면 TIME_WAIT상태가 되면서 서버에 ack segment를 보낸다고 하였습니다. 하지만 이 ack segment가 네트워 크의 오류로 인해 서버에 도착하지 못할수도 있습니다. 그런 경우라면 서버에서는 일정시간 이후에 다시 클라이언트에게 FIN segment를 보냅니다. 자신이 응답을 못받았으니 다시 보내달라는 의미지요. 만약 클라이언트가 CLOSED 상태 즉 연결이 닫혀 있는 상태에서 서버가 다시 보낸 이 FIN segment를 받으면 어떻게 될까요? 그런 경우라면 ack대신 RST라는 segment를 보내게됩니다. 즉 CLOSED 되면서 이전에 서버와 연결했던 정보들이 전부 없어졌으므로 서버가 다시 요청을 하면 "나는 너를 모른다. 왜 이상한 메시지를 보내느냐?" 하면서 서버가 원하는 ack 대신 RST라는 segment를 보내게 되는 것입니다. 이런 상황을 방지하기 위하여 일정시간 동안 TIME_WAIT라는 상태를 유지하여 서버가 다시 FIN을 보냈을때 대답할수 있게 해줍니다.

두번째에 대한 설명입니다.
다음과 같은 상황을 가정해 봅시다.
우선 현재 111.111.111.111:23 번하고 111.111.111.112:1500번이 연결되어 있다고 합시다.둘이 막 패킷을 주고 받다가 둘이 연결을 정상적으로 끊었다고 가정합시다. 그 후에 둘이 곧바로 연결을 해서 방금전과 마찬가지로 111.111.111.111:23 과 111.111.111.112:1500으로 연결되었다고 합시다. 근데 여기서 문제가 발생하였습니다. 바로 이전에 연결이 성립되었을때 111번에서 112번으로 보낸 패킷하나가 라우터의 오류로 인터넷을 뺑뺑이 돌다가 이전 연결이 끊어지고 지금 새로운 연결이 되었을때 112번에 도착했습니다. 무슨 소리냐구요? 예를 들어 라우터 A와 B가 있습니다. 근데 라우터의 일시적인 오류로 라우터 A의 데이타가 B로 전송하면 B가 다시 A로 그 데이타를 전송하여 순간적인 루프에 빠질수가 있을 수도 있습니다. 이렇게 루프에 빠지던 놈이 이전 연결이 끝나고 새로운 연결이 생겼을 때 도착한다면 문제가 발생하겠죠? 즉 원하지 않는 데이타가 전송되었으니 오류가 발생할 수 도 있는 것입니다. 이것을 방지하기 위하여 TIME_WAIT 상태를 둡니다. TIME_WAIT상태에 있는 동안은 같은 연결이 발생하지 못하도록 방지합니다. 즉 이전에 내가 연결되었던 포트가 1500번이라면 다음 연결은 현재 1500번이 TIME_WAIT이므로 1501번으로 연결되게 됩니다. 그렇게 하면 위와같은 문제를 해결할 수 있습니다. 보통 TIME_WAIT상태는 2 MSL입니다. 즉 인터넷 상에서 패킷이 존재하는 시간보다 길게 설정됩니다. 그러므로 TIME_WAIT상태가 끊나면 인터넷 상에서는 이전 연결에 보내졌던 패킷이 모두 소멸되었다고 확신할 수 있으므로 새로운 연결을 만들어도 문제가 발생하지 않는것입니다..

Dream, Passion and Challenge..

miso의 이미지

글쓴이: miso / 작성시간: 월, 2003/01/13 - 3:07오후

바쁘실 텐데도 이렇게 시간을 내셔서 답변을 해주셔서 감사합니다...
SO_LINGER 이 옵션은 클리이언트에 설정하는 거였군요...
저는 서버에 SO_LINGER 옵션을 달았었는데...
다시 한번 테스트 해 봐야 겠네요...
많은 도움이 됐습니다...
항상 행복하시고.... 하시는 일 모두 잘 되시길 빕니다... ^^

*^^*

killereco의 이미지

글쓴이: killereco / 작성시간: 수, 2003/02/26 - 11:21오전

리눅스 관련 network time_wait 설정 참고 자료입니다.

http://tunelinux.pe.kr/bbs/read.php?table=linuxinfo&no=76

miso의 이미지

글쓴이: miso / 작성시간: 수, 2003/02/26 - 3:23오후

늦게나마 답변주셔서 감사합니다.
제 작업에 많은 도움이 될 것 같습니다. (ㅡㅡ)(_ _)
^^

*^^*

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 화, 2013/04/02 - 3:43오전

test

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 화, 2013/04/02 - 4:11오전

진짜.. 다들 무식한 소리들 지껄이시네요..

당신들 정말 C 프로그래머들 맞습니까? 자료 서치하다가 잠시 들리게 되서 이 글들을

보고 있자니 답글을 안쓰고 넘어갈수가 없게 만드는군요? 정말 대한민국 프로그래머들의

네트워크 지식에 수치가 아닐수 없군요..?

질문자는 분명히, 언급하였습니다. 자바에서는 자기가 생각한대로 잘 작동하는데도 불구하고

왜 C 에서만 이런 증상이 발생하느냐구요.. 즉, 자바에서는 제대로 자기생각대로 작동이

TIME_WAIT 없이 잘 작동되더라라고 말하고 있었습니다. 그럼 질문자는 자명한 사실 하나를

두고 질문하고 있는 겁니다. 질문자가 이미 해답이 있는 자명한 사실을 갖고 어떻게 구현한거냐

라고 물으면 그에 정확히 알맞는 답을 해줘야지 동문서답 무식한 답변이나 하고계십니까?

자바도 코어는 C 로 만들어졌거든요? 즉, C 로 해결이 되는 사안을 갖고 질문하는건데 이미

해결되어있는 사안을 어떻게 구현하는거냐고 물어보는 건데 그냥 순응해라? 현실에 순응하라는 식의

답변? 장난 칩니까? 이미 자바로 된다는데? C 로 된다는건데? 이 무식한 프로그래머님들아..

제발 부탁하건데.. 그냥 이 사회에서 사라져주시던지 아니면 Guru(구루)가 좀 되실 수 없겠습니까?

C 언어 똥구멍으로 배우고 네트워크 똥구멍으로 배우셨습니까? 10년 동안 아니 15~18년 동안

개고생하면서 외길만 파온 C 언어 프로그래머 입장에서 본 결과 이 댓글에 작성하신 프로그래머님들..

진짜.. 실력 빵점 드리고 싶습니다.. 질문자의 질문요지에 맞게 C 언어 프로그래머 답게 답하세요..

그리고, 네트워크 프로그래머라면 적어도 이런 현상에 대해서 깊은 고찰을 해보고 해결해본적이 없으면

"TIME_WAIT 이 있어도 순응해라?" 이런 무식한 소리 안할겁니다.. 공부좀 하시고.. 연구들 좀

하시고.. 문제가 있으면 해결도 좀 하려고 애들 써보십시오..

나중에 C 언어 배우는 친구들도 검색하면서 KLDP 의 이런 답글들을 보면서 성장할텐데 후학들한테

쪽팔리지도 않습니까? 제가 보니 최초 질문자가 이 분야에서 능력이 더 출중한 친구같네요..

엄한 댓글로 무식한 소리나 하고 자빠졌으니..? 제가 정답 적어놓고 갑니다..

(정답)
-----------------------------------------------------------------------------
네트워크 프로그래밍을 하다보면 반드시, 이 문제(TIME_WAIT)를 안 겪고 넘어갈래야 안 겪고
넘어갈 수가 없습니다. 만약, 겪어보지 못했다면 공부를 다시하고 이 분야에서 충분한 경력도
없으신 분일 겁니다.. 이 TIME_WAIT 가 발생하는 문제는 심각한 문제입니다. 왜? 그러느냐?
엄청나게 빠른속도로 접속하고 엄청나게 빠른 속도로 종료되는 시스템에서는 이 TIME_WAIT 문제는
심각한 상태를 만들어냅니다.. 자원고갈되는 사태를 벌어지게 만듭니다. 위에 최초 질문자가
구현한 프로그램은 while 로 도는 무한정의 접속 및 종료의 클라이언트 연결을 만듭니다.
이런 프로그램은 포트 스캐너 같은 프로그램과 유사한 면이 있습니다. 저도 예전에 경험한 적이
있는데 수많은 접속과 종료가 순식간에 발생하면 서버 뿐만 아니라 클라이언트에서도 자원고갈이
발생합니다.. netstat 로 보게되면 TIME_WAIT 상태가 산더미 같이 쌓이게되죠.. 그럼 나중에
접속을 더이상 할 수가 없게됩니다.. 왜? 자원고갈 상태가 되어버립니다.. 소켓이 죄다 열려
있는 상태인데 사용할 포트는 65535 가 최대거든요? 이 문제가 서버에서도 발생합니다..
그래서, 클라이언트가 명확하게 접속을 끊는 경우와 서버가 명확하게 접속을 끊을 경우에는 반드시
TIME_WAIT 없이 깨끗한 상태로 끊어져야 합니다. 그래야 접속폭풍이 일어나는 기업의 상용서비스에
대응할 수 있게되는거죠.. 대기업 서버가 자원고갈이 발생해서야되겠습니까? 무식한 서버가 되는
거죠.. 그리고, 그런 문제는 자바에서는 이미 처리되고 있습니다.. 아~주 깔끔하게.. 그럼, 그게
어떻게 한거냐?

(정답)
- 서버에서 클라이언트를 명시적으로 끊었을때 TIME_WAIT 가 발생하지 않으려면..?
shutdown(sock, sd_both);
closesocket();
소켓을 닫기 전에 셧다운을 시켜야 한다. 그럼, TIME_WAIT 없이 깔끔하게 끊어진다.

- 클라이언트에서 명시적으로 끊어서 TIME_WAIT 가 발생하지 않으려면?
그건 위에 댓글 단 사람들이 이미 설명했다. SO_LINGER 써라..

-(요약)
서버에서 폭풍접속 종료에 깔끔하게 TIME_WAIT 없이 명시적 종료를 하려면 shutdown 을
쓰고, 클라이언트에서 폭풍접속 종료에 깔끔하게 TIME_WAIT 없이 명시적 종료를 하려면
SO_LINGER 에서 타임을 0 으로 바꿔라..
이렇게하는 이유는 어마어마한 속도로 접속과 종료를 반복해서 무한정 돌려야하는 클라이언트와
서버 프로그래밍에서 자원이 고갈되지 않도록(디스크립터 자원고갈 발생 방지) 하기 위함이다.
이걸 지키지 않으면 최초 접속자가 헤메는 그 증상이 나타난다. 즉, 서버와 클라이언트 양쪽
에서 이 규칙을 지켜야 합니다. 어느한쪽이 안지키면 그 안지킨 한쪽은 폭풍접속 및 종료에
있어서 결국에는 자원고갈되며 병신되는거죠..

P.S:
이 문제를 해결하지 못하는 대다수의 프로그래머들이 머리싸메기 싫어서 결국 자바를 쓰게되겠죠?
결론은 실력없는 프로그래머들이 자바를 쓴다.. 실력없는 프로그래머들이 스크립트 언어를 쓴다..
실력없는 사람들이 이런 C 만의 세세한 제어를 다 극복하지 못하고 머리 싸메다가 그냥 자동화해주는
편의성 때문에 자바나 기타 언어들로 빠지게됨.. 그래서 나중에 대화를 해보면 무식한 소리나 찍찍
해대면서 프로그래머라고 그러고.. 문제 발생하면 해결도 못하면서.. 그런 인간들이 한국에는 너무
많이 양산되어 있습니다.. 짜증이 날 정도로 말입니다.. 이런 문제도 해결못하면서 무슨 자바 프로
그래머를 한다는건지.. 한국도 정말 C 로 다방면의 프로그래밍을 쩔만큼 잘하는 사람들이 자바나
기타 다른 언어로 옮겨타는 그런 사회가 되길 바랍니다.. 미국은 VB 프로그래머라고 허접하게 봤다간
개코다칠만큼 많이 알고 있는 사람들이 산재한데.. 한국은 -_-; Little Endian 도 모르는 사람이
프로그래머 10년차인 경우도 산재함..(바이트오더도 모르는 사람이 네트워크 프로그래밍을 하는 나라..)
제발..
한분야의 장인이면 좀 공부들 좀 하세요.. 공부들 좀.. 아니, 공부만 한다고 되는게 아니니.. 극복들
하는 자세좀 키우십시오.. 맨날 문제 발생하면 자바로 옮겨탈 생각이나 하는 인간들이 너무 많아서리..

-- by AmesianX(amesianx@gmail.com)
뭐 따지고 싶은거 있으면 이리로 연락하셈.. 쓰레기들 항의는 얼마든지 상대 해주겠음..

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 화, 2013/04/02 - 4:59오전

C 언어의 장점은 세세한 제어를 직접 프로그래머가 수동으로 제어해줘야 한다는데에
있습니다. 이 말은 아는게 많을수록 무궁무진하다는 것이죠.. 반대로 아는게 없으면
제일 정내미 떨어지는 언어도 C 언어입니다.
그래서, 가끔 이런 경우들을 봤습니다. 다른 언어를 하는 분이 제가 프로그래밍 질로
매우 신기한 짓거리들을 하니까 부러워 하더군요. 사실, 다른 언어도 안되는 건 없습
니다. 다른 언어들도 C 만큼 다 제공합니다.. 안하는게 절대 아니죠.. 단,
다른 언어들은 C 보다 더 많은 디폴트 기능들을 제공하고 있습니다. 흔히, 말하는
자동화 기능들을 디폴트로 제공하는 경우들이 많다는 겁니다. 그래서 C 언어 프로그래밍을
택한 사람들보다 더 적은 문제점들에 봉착하게되죠.. 이 말은 프로그래밍하면서 발생하는
문제들에 대한 극복하는 자세가 시스템 프로그래밍 언어에 핵인 C 를 하는 사람들보다
훨씬 못하다는 얘깁니다. 얘를들어 메모리 자동해제를 지원하는 요즘의 신세대 언어들은
그만큼 안전한 반면 그런 메모리에대한 생각자체를 안하게 만들죠.. 마치, 암산을 하던
사람이 계산기를 오래쓰면 머리가 굳어버리는 것 처럼 만들게되는 효과를 가져옵니다.
아니, 처음부터 C 나 어셈블리를 깊이 공부하지 않고 상위언어부터 한 사람들은 더더욱
이런 문제점에 대한 의식이 없습니다. 왜냐면, 신식 언어일수록 자동으로 디폴트로 기능을
덧붙여 놓은걸 쓰거든요..
그래서, C 언어 중에서 제일 인기있는 VC++ 나 GCC 같은 것들도 다 상용 라이브러리가
있는 이유입니다.. 실력없는 C 프로그래머를 서폿하기 위해서 상용 네트워크 엔진들이라던지
그런걸 팔고 있는거죠.. 누가? 실력좋은 엔지니어가 개발해서 팔죠.. 모든걸 다 고려하여
프로그래밍해놓은 라이브러리를 말입니다..
만약, 맨 위에 최초 질문자가 만약 네트워크 엔진 라이브러리를 사서 사용했다면 질문을 하지
않았겠죠.. 상용 라이브러리에는 디폴트로 구현되어있는게 그런 사소한(하지만, 초보자들이
매우 해결하기 어려운) 것들에 대한 대비책입니다..
괜히 상용 라이브러리를 사서 쓰는게 아니죠.. 이런 TIME_WAIT 같은 문제들 뿐만이 아니라
수도없이 복잡한 구현들이 필요하고 실수가 나올수 있는 부분들을 오랜시간 동안 다듬어온
엔지니어가 만들어서 파는게 엔진입니다.. 라이브러리이구요..
그런데, 그것만 갖다 쓰는 사람은 실력이 절대 늘수가 없죠..? 왜?
문제 해결능력을 키울 기회의 상실 때문입니다.. 게다가 상용엔진이나 라이브러리만 쓰던
사람들은 그 의존도가 높아서 그걸 못쓰게되는 프로젝트에서는 병신되는거죠.. 그래서 자꾸
운영체제에서 기본으로 지원되는 API 를 사용하라고 조언하는 것도 그런 이유죠.. 어딜가나
적응력은 최고니까요.. 스크립트 언어중에서 가장 최고의 스크립트 언어가 PYTHON 도 아니고
PHP 도 아니고 RUBY 도 아니고.. PERL 이듯이.. 왜? 이런경우도 있거든요..? 어떤 시골
깡촌 군부대에 유닉스가 고장나서 아무 지원도 못받고 인터넷도 없는데 가서 뭔갈 해결해야하는데
자동화 시켜야함.. 그럼 쉘스크립트 다음에 사용할 수 있는건? 펄이 가장 우선순위임..
당연히 컴파일러따위는 안깔려있다던지.. 쉽게 말해서 어떤 심각히 열악한 상황에서도 반드시
있는 것이 PERL 인 것처럼.. 아주 가장 최악의 시나리오에서 프로그래밍을 해야한다고 했을때
존재하는 유일한 기본단위가 운영체제의 API 임.. 그런 자세로 공부해야하는데 라이브러리
의존도를 높이면 결국 정말 위급(?)하다 표현할 수 있는 일생일대의 프로젝트에서 병신될수도
있게될 확률이 존재하게된다는 얘기가 될 수 있는 것임..
얘를들어서.. 자기가 정말로 하고 싶은 프로젝트인데.. 자바를 쓰지 않고 시스템 완전 밑바닥
에서 해야한다면? 예를들어 임베디드같이? 요즘은 임베디드에서 자바가 다양하게 지원되고있긴
하지만은.. 정말정말 아주 용량이 작은 소형장치인데 간단한 네트워크 통신이 되게 만들어주면
막 10억 준다고 해달라고 하는 사람이 나타난다면? 그런 상황이 되는데 실력이 없어서 놓친다면?
그런 일들은 극단적인 비유이지만 사람이 살다보면 다양한 프로젝트에서 이런 비슷한 절체절명의
일들이 유사하게 많이 벌어짐.. 똑같진 않지만 다양하게 그런 환경이라는게 조성된다는 것임..
그런 환경에서 최소단위로 내려가면 어셈블리가 되겠지만은 그보다 바로 윗단계에 존재하는게
C 언어이고 그만큼 자유도를 제공한다는 얘기임..
제공하는 자유도 만큼 디폴트 기능이 자제되어 있다는 얘기고 그만큼 많은 문제들에 직면할 수
밖에 없다는 얘기이며, 이런 문제들을 하나하나 격파해가면서 성장하는게 C 프로그래머들임..
그래서 되는건데도 불구하고 안되니까 순응하라는 말을 들으면 눈이 돌아버림.. 왜?
이 세상에 컴퓨터 공학이라는 학문에 한정하여 C 로 안되는게 어딨다고.. 그런 소리들을 하는건지..
여튼..

최초에 적을때 다른 지인이 부러워하더라는 말을 꺼냈었는데.. 다른 언어들도 충분히 다 지원
하고 다 있는 기능이 C 언어에도 다 있다는거.. 그리고 동급이라 할 순 없지만 대부분의 언어는
다 똑같다는거.. 니가 델파이를 아니? 라면서 까는 인간들도 있고 니가 VB 를 아니라면서 까는
인간들도 있고 서로 자기언어 잘났다고 서로 까대지만.. 적어도 한가지 분명한건..
적어도..
C 언어하는 사람들만큼 개씨발 빡빡 바득바득 바닥을 긁으면서 오만 문제들을 격파하면서 커오는
인간들을 없다는 사실임.. 왜? C 언어가 어셈블리라는 기계어 즉 CPU 언어와 가장 가까운 면에
닿아있기 때문에 발생하는 현상임.. 그렇기 때문에 가장 많은 심각한 문제들과 직면하고 해결을
못하면 프로그래머를 할 수가 없게되는 면이 있는 반면.. 다른 언어들은 최소한 C 언어 프로그래머들
보다는 항상 더 많은 혜택을 받고 있다는 것임.. 즉, 언어 자체는 같은 형태의 지식을 요구하는데
대비.. 그 언어를 사용하는 사람들이 문제라는 얘기로 귀결되는 것임.. 그 환경.. 즉, 언어를
하는 사람의 환경이 C 인 경우에는 극복해야할 것들이 너무도 산재한 반면 다른 언어를 사용하는
사람들은 그 극복해야할 상황이 상대적으로 적다는 얘기임.. 왜? 다른 언어가 그만큼 C 언어 이후에
출현함으로 인해서 많은 부분을 배려해주려고 했기 때문에 발생하는 현상임..
쉽게 말해서 쓰레기 C 언어 프로그래머는 잘하는 자바 프로그래머보다 병신일 수도 있다는 얘기임..
그러나, 똑같이 만약 C 언어 10년 자바 10년을 두명이 각각한다면..? 10년 뒤에 누구 지식이 더
높은가를 따지면 C 언어 프로그래머가 더 실력이 높을 수 밖에 없는 언어 태생적 구조가 존재한다는
것임.. 물론, 둘다 똑같은 노력을 기울인다고 했을때를 가정한 것임..
그럼, 똑같이 말하면 어셈블리 10년 C 언어 10년을 한 경우를 놓고 본다면? 똑같은 전제하에..?
그럼, 어셈블리 10년한 사람이 실력이 더 높은건 당연한 것임.. 왜? 언어의 레벨 때문에 발생하는
극복과제들에 대한 근본적 차이가 있기 때문임.. 근데도 무슨 언어별 쓰레기 같은 논쟁들이 너무나도
많음.. 그런 언어갖고 논쟁하는 사람들 앞에서 매직같은 기술을 보여주면 나중엔 부러워하는데..
나도 C 배우고 싶은데 어떻게 하는거냐면서.. 심지어는 볼랜드 개발자가 VC++ 프로그래머를 부러워
하질 않나.. 그런 일들이 오랫동안 C 프로그래머로 실력을 갈고 닦으면 주변에서 벌어지는 일들임..
이 얘기는 언어 문제가 아니라..
언어사용자의 문제..
즉, 자기극복의 문제..
자기극복이란 어디서 시작하느냐?

위에 이 글의 최초 댓글자가 질문한 내용을 해결하는 것에서부터 시작한다..

라는 겁니다..

극복자세.. 한가지 제가 알고 있는건 C 언어 프로그래머로써 이 쓰레드의 최초 질문자가 겪은 증상을
경험하고 해결하려는 자세가 중요한 것임.. 심지어 파이썬 신봉자들도 요새 많은데.. 똑같은 네트워크
프로그래밍인데 파이썬으로 짠건 결과가 잘 나오고 C 언어로 똑같이 짠건 결과가 잘 안나오는 경우들도
있음.. 왜 그런지는 모르나 특별한 환경하에서 그런 경우들이 나옴.. C 언어의 처리속도와 파이썬의
처리속도가 극명하게 느린 네트워크 환경이나 멀리 미국쪽 통신을 해야하는 경우라던지 불안정한 네트워크
라던지.. 그런 경우에는 파이썬이 안정적이고 C 가 불안정함.. 왜 그런가..? 불안정하니까 C 가 병신
이고 파이썬은 그런경우에도 안정적이니까 좋은건가? 이 문제는 C 가 그만큼 더 디테일하게 작동하고
그만큼 더 빠른 속도로 작동하기 때문에 벌어지는 일들이라는 얘기로 바라봐야 하는데 파이썬 신봉자는
거봐라 파이썬이 더 좋다라는 말을 할 수도 있음.. 그러나 정말로 엔지니어라면 그런 특수한 일이 벌어지면
C 에서 왜 그런 불안정한 네트워크에서의 현상이 벌어지는지 반드시 알아낼려고 들 것임.. 파이썬은 느리기
때문에 오히려 안정적으로 작동하고 C 는 빠르기 때문에 되려 불안정해진다..? 특수한 네트워크 환경일 경우?
그럼.. 이러한 처리를 다 고려해서 구현해줘야 한다? 그럼, 불편한 언어인가? 불안정한 언어인가? 디테일한
언어인가? 이렇게 생각해보면 됨.. 메모리가 초소형인 임베디드에도 C 로 프로그램을 만들어서 작동시키는데..
그런 일을 반드시 해야할 수 밖에 없는 특수한 환경에 봉착한다면.. 예를들어 강도가 들어와서 칼을 들이밀고
초소형 임베디드 칩을 주고 여기에 프로그래밍하라면?(? -_-; 물론, 이건 대단히 비약적인 발상이고 허구이지만..)
이 세상을 살다보면 대단히 많은 변수들의 환경에서 일을 하게되고 특히나 프리랜서로 일하는 프로그래머들은
더 변화무쌍한 황무지에 놓여있는데.. 이런 잡초같이 살아남을 수 있는 실력을 기를려면.. 최악의 상황을
항상 가정하고 그 최악의 상황을 이겨낼수 있는 실력을 즉, 지식을(경험력을) 길러야 됨..
그래서 C 언어를 해야한다는 것임.. 그런 능력을 배양하기 위해서.. 그만큼 개고생을 해야한다는 거고..
뭐 하나 프로그램을 짜도 한번도 단기간에 작동한 적이 없는 프로그래밍을 C 로 개고생하듯이 한 10년 15년
하다보면.. 그때서부터는 머리속에 들어있는 걸로 무슨 프로그래밍이던지 짜내면 척척척 잘만 되는 그런 고수
그런 구루가 되어야 완벽한 프로그래머라는 이야기임..
극복자세를 기릅시다.. 시발.. 개허접한 프로그래머가 되시지 마시고.. 맨날 책만 집착해서 실제 사용도 못해
먹는 기술만 파지 마시고.. 현실에서 개뻘짓들 많이들 해보시고.. 개뻘짓 실력 == 진짜 실력임..

<이론은 해석용, 뻘짓은 실력용>

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 화, 2013/04/02 - 9:25오전

위에 양반을 보니... 자신만의 우물에 갇혀서 자신이 보는 하늘이 전부라고 생각하는 개구리.. 진부한 표현이지만.. 그 개구리가 생각나네요.

위의 답글을 제대로 읽어보긴 한건지.

shutdown()을 호출하면 time_wait 가 안생긴다니 아놔... 당신 네트웍 프로그래머 맞어?

tcp 프로토콜 만든 사람이 니가 생각하는 그런 짱구라서 괜히 time_wait 를 만들었다고 생각하나?

네트웍을 안다고 깝치려면 적어도 스티븐스 책을 1회라도 정독하고 와라. 어쭙지도 않은 잘못된 지식으로 남들 비난하지 말고. 너같은 놈들만 있으면 누가 어디 무서워서 답글 달겄냐? ㅋ

참고로 잘 정리해놓은 링크 하나 보낼테니... 프로토콜 연구할 능력도 노력도 없다면 이거라도 읽어보길.

http://kuaaan.tistory.com/118

수고해라 후배야.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 화, 2013/04/02 - 9:29오전

특정 컴퓨터 언어가 무슨 니 모국어라도 되는듯 애정을 갖고 있는거... 엔지니어라면 그런 건 걍 똥고집이야..

언어는 말이다.. 그저 생각을 구현하기 위한 매개체인거다.

씨로 다 할수 있겠지. 하지만 너 강도가 총들고 '10분 줄테니 웹서버 만들어 씹새야' 그러면... 씨로 만들겠니 자바로 만들겠니?

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 수, 2013/04/03 - 12:51오전

질문자가 자바에서는 안생긴다고 그랬다.. 빙신아.. 그렇게 코딩하는 방법이
shutdown 이다.. 빙신아.. 이건 지큐어웹이던가 INISIS 던가 미들웨어 서버
만드는 걔네들 개발자 블로그에도 이미 기록되어있는 정보다.. 병신들아..
모르면 좀 처배워.. 뒤질라고 어디서 까데..
그리고, 스티븐스 네트워크 책은 이미 13년 전에 읽었던 책이다.. 병신 같으니..
질문자에게 제대로된 정보를 줄 생각은 안하고 너네같은 애들이 프로그래머를
하니까 후학 실력들이 개판아니야! 반성들좀 해라..!
그리고, 넌 내가 쓴 글 제대로 처 읽어보지도 않고 지껄이고 있는데?
특정언어가 중요한게 아니라 C 라는 언어가 처한 환경이 열악한 환경을 제공하는
기본 습성이 있다고 말했다. 그래서 극복해야할 과제가 더 많은 언어태생이 있기
때문에 실력이 더 늘 수 밖에 없다는 얘기를 했다. 이건 언어태생적인 문제다.
그리고, 이런 언어 태생적인 문제가 있어도 극복하려는 언어사용자의 자질이 안되면
말짱 도루묵이라고 그랬다. 다만, 극복하려는 자세를 가진 두명이 C 와 자바를
선택하면 당연히 C 를 택한 사람이 더 많은 열악한 환경을 겪기 때문에 실력이 더
좋을 수 밖다고 전제를 깔아서 얘기를 했다.. 병딱아..!
그리고, 내가 강도얘기를 꺼낼때 분명 전제를 깔았다! 임베디드 환경에 최소형
메모리라는 전제를 말이다.. 병신아 최소형 환경에 자바를 어떻게 써? 넌 그러니까
안되는거야.. 운영체제도 못배운 티를 내는거 같어.. 바보같으니... 임베디드
PIC 칩에 자바를 어떻게 써? 이 병신아! 메모리가 몇킬로 바이트 밖에안되는데 자바를
써? 바보아니야? 쓰레기라고 해줄께.. 공부좀 해라.. 등신아..
어셈블리를 써도 모자를 판국에 자바를 지껄이고 자빠졌네.. 강도얘기를 할때
내가 분명 전제를 깔았다.. 니가 공부를 해도 눈에 병신정보만 들어오는 이유가
내 글에 대해서 이해를 못하기 때문이야.. 어떤 책이던 항상 정보는 전제를 깔고 얘기를
하거든? 근데 너는 내 글에서 전제 정보도 못찾아내고 무슨 스티븐스를 지껄이고 난리야?
하찮다 인간아..

그리고, 최초 질문자 혹시 이 글을 보게되거든 shutdown 을 찾아보시오.. 그리고 직접
적용해보시오.. 내말대로 안되면 시발 내가 18년 동안 C 프로그래밍 마스터한거 똥구멍으로
공부한거다.. 안되면 내 손에 장 지질께.. 쓰레기같이 댓글 다는 선배들 다 무시하시오..
어셈블리하나 제대로 못 읽는 C 프로그래머들이 천지빼까리니까..
공부를 할려면 제대로된 사람에게 배워야지.. 대한민국 수준 너무 낮다.. 지식으로 무장
했다는 쓰레기들 중에서 이론도 허투루 배운 놈들이 빼곡할 뿐만 아니라 실전용 개삽질도
제대로 안해본 인간들이 너무많어.. 그리고는 지가 프로그래머래..
근데, 달아놓은 댓글 봐바.. 지나가는 개가 웃고 가겠다..

후학들이여 한글로 된 정보를 보지 마시오.. 죄다 쓰레기 아니면 영어 블로그에서 퍼다
나른거니까.. 병신들이 하는 짓이 퍼다나르는 건데 그럴꺼면 차라리 항상 원서 읽으라고
하듯이 외국 블로그의 영문으로 된 정보를 주로 보고 공부하시오.. 그리고, 주변에서 항상
원서로 공부하라는 선배말만 들으시구료.. 후학들이여.. 왜 이렇게 말하고 있느냐?
한국은 항상 영어로 생산되는 정보를 한국어로 만들면서 정보를 왜곡하기 때문이오.. 정보의
외곡현상이 번역이 잘못되서 나오는게 아니라 그 정보를 이해를 못하고 지껄이는 인간들이
너무 많아서 그러오.. 그러니, 후학들이여.. 원서로 공부하라라는 조언을 하는 선배의 말을
귀담아 듣기 바라고.. 이런 곳에 쓰레기 댓글 다는 인간들이 있음도 인지하기 바라오..
내가 왠만하면 그냥 그동안은 지나치고 말았는데.. 특히나 이런 동문서답 해결도 안되는
답변들을 다는 인간들이 보이면 한국에 태어난게 원망스러울 정도로 답답해 진다오..
한국 정보는 보지말고.. 영문으로된 사이트만 뒤지면서 프로그래밍 공부를 하는게 좋을꺼요..
쓰레기들 열심히 미국자료 퍼다 나르지만 정작 자기가 험난 프로그래밍 문제를 극복한 주제로
글을 써서 소중한 자료를 공유하는 인간들은 내 본적이 없소이다.. 극복한 주제는 고수
프로그래머들은 정보공유 안합니다.. 한국의 고질병(?).. 그니까, 정말 잘하는 인간들은
이 게시판의 댓글 처보고도 근야 지나친다는 말임.. 그래, 난 해결방법 아는데 개고생좀 해봐야지?
이러면서 지나친다는 말임.. 본인도 처음에는 "나랑 똑같은 문제를 경험한 인간들이 있기는
있구나" 하면서 코웃음 치고 지나치려 했으나 중생이 불쌍하여 댓글을 달아주고 가는거니..
대부분의 고수들은 지나치고 간다는 사실.. 특히나 이런 문제는 엄청난 집요함이 없으면
질문자 스스로는 해답을 찾아내기 힘든 이런 문제들.. 요런거는 왠만하면 안가르쳐 줍니다..
후학들 명심하기를.. 고수들은 당신들이 개뻘짓하고 바득바득 기기를 바라며 안가르쳐준다는거..
왜?
"나는 바득바득 기면서 상황별 해결책을 알아냈는데 너는 숟가락만 얹겠다고? 한번 너도
바닥부터 기어봐라"
라는 심보가 미국이 아니라 한국 프로그래머들의 기본 나쁜 심보 때문이오.. 그만큼 현실이
살기 어렵기 때문에 그런식으로 인간들이 썩었을런지는 모르지만 고수인데 썩은 넘들은
공유안합니다.. 특히나, shutdown 같은 거는 인터넷에 정보가 이미 많이 있습니다.. 중요한건

"질문자가 처한 상황" + "정답은: shutdown"

이렇게 정보를 공유하거나 모아놓은 사람은 인터넷에 없다는 겁니다.. 지식은 shutdown 이고
고수의 뻘짓실력은 "상황" + "shutdown" 이기 때문에 백날 초보들이 shutdown 정보를 봐바야..
close 해도 소켓은 닫히는데 shutdown 을 쓰겠냐는 것임.. 그러다 최초 질문자 처럼 특별한
상황에 닥쳐야 이상하다(?) 그렇게 생각하는거임.. 이해되나? 상황별 프로그래밍 능력이 바로
실력이라는 걸? 지식은 깔려있다.. 그리고 이러한 지식들을 많이 알고 있다고 해서 자기자신이
고수라는 위에 댓글다는 쓰레기들도 많다는 얘기임.. 지식이 고수를 판가름하게 만드는게 아니라
상황별 지식을 정확히 알고 있는 사람이 고수요.. 알겠소?
그리고, 최초 질문자는 특정상황을 얘기했고, 그 상황을 해결할 지식을 자기머리속에서 꺼내서
알려주는 사람이 고수요.. 알겠소? 대다수의 지식을 많이 알고 있다면서 상황은 다 빼놓고 책에서
처본 것만 나열하는 인간들이 천지빼까리고.. 알겠소?
후학들이여.. 한시도 쉬지말고 뻘짓을 하길 바라오.. 그래야 상황별 지식능력이 늘지 백날 책
처본다고 실력느는게 아니외다.. 이펙티브 C++? STL? 스티븐스의 네떡책? 조엘온 디자인패턴?
뭐 이런거 짓거리는 인간들 중에서 제대로된 프로그래머 없다는 사실만 명심하시오..
어떤 개 쓰레기 프로그래머는 private 으로 선언하면 그게 컴파일러의 문법상 접근제약을 거는건데
프로그램이 실행되는 런타임 중에도 제약을 걸어주는 걸로 생각하는 개 쓰레기 프로그래머들도 많소..
C++ 의 thiscall 규약이 뭔지 어셈블리로된 기계어를 C++ 로 타입변환 시키면서 thiscall 멤버함수
강제호출하는 방법도 모르는 개쓰레기 프로그래머들이 천지 빼까리요..
미국애들은 한가지 언어를 연구하면 아주그냥 잘게잘게 부셔서 먹어버릴 정도까지 연구해서 그걸
다시 영어로된 책으로 출판하는데 한국에서는 이런인간들이 없소.. 달래 영어 원서로 공부하라는게
아니고.. 그리고, 이런 책이 나온다한들 그걸 단순히 처읽는다고 자기께 되는게 아니외다.. 자기가
그런 문제에 봉착해서 직접 타이핑 해보고 문제를 개고생해서 해결해야 머리속에 각인되서 남는거지..
한국에 자기가 사용하는 언어를 어셈블리 수준에서 꿰뚫고 바라보는 인간들이 몇이나 있을 것 같소?
후학들이여..
인터넷에는 오만 잘못된 정보들이 넘쳐나니.. 가려서 공부할 수 있는 능력을 기르시구료.. 아니면
영어로된 사이트를 돌아다니면서 공부하시오.. 최소한 그곳에는 왜곡된 정보는 없으니까..
이 시발.. 한국.. 개 쓰레기들.. 정보왜곡에 선수들..

달래 미국에 가야 성공한다는 얘기를 하는게 아니외다..

P.S: 대표적인 정보왜곡으로 발생한 사건.. ActiveX 기술이 있소.. 당신들 중에서 COM 이 ActiveX 라는
사실을 아는 인간들이 꽤 있다면 COM 이 DLL 확장 모델패턴을 갖고 있는 것 까지 깊게 파본 사람
있소? 프로그래밍 기법까지? COM 메쏘드 구현법까지 파본사람 있소?
본인이 두 저술을 했으니.. 인터넷에서 "Art of hooking" 이라는 문서와 "ActiveX 함수 분석법"
이라는 두 문서를 찾아서 보시구료.. 최소한 프로그래머라면 아무리 무능력해도 이정도는 파봐야지..?
COM 모델이 DLL 확장 프로그래밍이고 구현호환기법인데 이 프로그래밍 모델을 제대로 이해를 했다면
오늘날 대한민국이 ActiveX 쓰레기 나라는 되지 않앗을 것이오.. COM 프로그래밍 모델을 제대로 이해를
하지 못하고 기술적 지식만 습득한 개 쓰레기 프로그래머들이 DLL 확장구조를 활용하지 않고 지멋대로
개프로그래밍 기법을 난발해서 대한민국이 이모양 이꼴이 되었소..
본디.. 프로그래밍이란.. 속성이 이런거요..
"코드는 무조건 짜면 작동한다.."
코드란 짜면 무조건 작동하오.. 무조건이오.. 컴파일러가 문법 오류낸다고? 컴파일오류? 링크오류?
이건 당신사정이고.. -_-; 어셈블리로 보면 모든 코드는 쓰는대로 작동하게 되어있소.. 오직 기계어는
작동하기위해 태어난 거요.. 그 기계어를 갖고 요리조리 대가리 굴려서 "간접지정 마술을 통해서 태어난
언어들"이 최초가 C 였소, 그리고 C 를 갖고 또 간접지정 매직을 부려서 태어난 언어들이 바로 그 상위의
언어들이요.. 코드는 무조건 짜면 작동하오.. 무조건이오.. 그런데.. 이 설계를 한 사람들은 규율을 정했고
그걸 모델이라고 불렀소.. 이 말은.. 규율.. 반드시가 아니라 지켜야 옳다는 사상(추상)을 심어놓았단거요..
더 쉽게 말하면 싱글톤이고 개 지랄패턴이고 따르면 좋은거지.. 따르면 효율적이고 편리한거지.. 반드시가
아니오.. 어셈블리 단에서 보면 반드시라는 것이 없소이다.. 근데, 규율을 지키지 않은.. 아니.. 사실상..
미국애들이 규율을 졸라게 설명해줬는데.. 지식만 처읽고 속성에 대한 깊은 고찰도 하지않는 개 쓰레기
프로그래머들이 코딩만 하면 처작동하니까 난발해서 만들어버리는 바람에 MS 는 ActiveX 를 지원중단 선언
했소이다..(물론, 브라우저에만..) 여기서 우리가 뭔 교훈을 얻어야 하는지 아시오?
시발.. 대한민국은 너무 지식주의적이다..
쉽게 말해 위에서 지껄인 인간처럼 이미 본인은 13년 전에 읽은 책을 앞세워 읽어봤냐면서 신봉하는 그런
문화가 있다는거.. 정작 패킷상에서는 제대로 처파악도 못하면서..
이렇게 되면 무슨 오류가 발생하냐면 너무 이론에 치우치거나 혹은 이론을 간과하거나 하는 실수를 범합니다.
어느 한쪽으로 치우쳐버린다는거.. 예를들면 한쪽은 이론을 졸라 외치고, 다른 한쪽은 이론을 쓰레기 취급
하고 이론은 뭣도 모르면서 실전을 외치는 인간들도 있소.. 이 두가지는 하이브리드로 보강되어야 하는건데..
한가지만 치우치게되면 절름발이가 되는거요.. 이론+실전력이 둘다 강해야하고 그래야 어떤 한가지 기술에서
이해력이 깊어지는것이오.. 그러면 ActiveX 병신나라도 안만들어졌을 거요.. 왜? COM 에 대해서 DLL 확장
모델을 프로그래밍 기법상으로 분석해보면 MS 가 얼마나 DLL 기본특성 갖고 교묘하게 프로그래밍한 아이디어인지
뼈저리게 느꼈을것이고, 그런 실전실력을 기반으로 COM 프로그래밍 모델이라는 서적을 읽었다면 사람들이 아마
다 달라졌을 것이오.. 그런데, 대다수의 쓰레기들은 어떻게 공부하냐면 누가 ActiveX 컨트롤을 하나 만들어
달라고 하면 대부분은 남에소스 긁고 그 기본작동 코드 원리만 갖고 주먹구구 붙여서 내다팔았던거요..
스파게티도 모자라서.. -_-; 이런걸 보고 바로 그냥 지식이라고 부르는거요.. 나 코드 짜봤다.. 작동한다..
작동만하면되지.. 이런 개쓰레기들이 ActiveX 메쏘드갖고 매직부리듯이 하면 입떡 벌리고 침이나 질질 흘리지..
원리를 처 모르니까.. 원리를 처 모르는 인간들이 너무 많고, 동시에 원리는 책이라는 것만 오직 판 개 허접
실전력도 없는 인간들이 동시에 많소.. 하나로 치우쳐있다는 얘기임..

이론은.. 해석용이요..(매우 중요하오) 뻘짓은 실전용 실력용이요..(매우 중요하오)

뻘짓에 강하고 실전기술에 있어서 타의 추종을 불허할 정도로 연구하고 동시에 자기자신이 하는 뻘짓에 대해서
완벽하게 이론적 서술을 할 수 있는 프로그래머들이 대한민국에 몇이나될까..?

이런게 안되서 대한민국이 ActiveX 나라로 썩어가도 아무도 안나서는 거요.. 아니.. 못나서는 거지.. 처모르는데..
어딜나서.. -_-;

그래서.. 한만은 프로그래머들이 가능성이 보이는 후학들을 보고 미국으로 처 가라고 조언하는거요..
그 나라에는 고수가 천지에 깔렸으니까.. 걔네들은 지 모국어니까.. 그냥 처 훑어만 봐도 안다니까? -_-;
한국은 바득바득 기어야 속성까지 아는걸.. 걔네들은 천지 사방에 개고생하고 연구한 놈들이 그 속성까지
아니 언어적으로 느껴지는 느낌까지 책으로 써서 뒤이은 개고수들을 길러내는데..
한국에 출판 안되거나 출판되도 몇년 후가되는 그런 개고수들의 서적이 대체 몇권이나 되는지 당신들은 아시오..?
그나마 외국서적 깊이도 모르면서 아주 쪼금 간이라도 처본 놈들이 지 잘났다고 스티븐스 외치면서 조엘온 외치면서
쓰레기처럼 목소리 내는게 한국의 프로그래머들 바닥이외다..
한심하기는..
IOCP 랑 epoll 갖고 개쓰레기 논쟁들을 하질 않나.. 에휴.. 개 허접데기들.. 다들 그냥 나가 뒤졌으면 좋겠네..

Stand Alone Complex의 이미지

글쓴이: Stand Alone Complex / 작성시간: 수, 2013/04/03 - 1:12오전

AmesianX님 좋은 정보, 좋은 글 고맙습니다.
감사합니다.

RET ;My life :P

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 수, 2013/04/03 - 1:31오전

// 최초 질문자에게..

프로그래머로써 소스에 대한 욕심이 없으면 그건 프로그래머아 아니외다..
평상시에 취미가 인터넷에 svn 이나 git 을 돌아다니면서 소스를 모으거나
과거로 친다면 PC 통신을 뒤지면서 자기가 관심있는 소스를 미친듯이 뒤져본
경험이 없다면.. 그건 프로그래머로써.. 자질이 없는거요..
소스에 대한 탐욕.. 욕심..
없다면.. 프로그래머로써 포기하는게 좋소..
만약, 당신이 정말로.. 프로그래머로써 실력자가 되고 싶다면 이런데 질문하지
않고 해답을 찾아낼 수 있어야하오. 심지어는 자바코드도 뒤졌어야 하오.. 왜?
거기는 제대로 작동하니까.. 소스? 인터넷에서 구할 수 있을 테니까.. 미친짓?

당연히, 미친짓..

그 정도의 미친놈 같은 발상으로 사고하고 인터넷에서 내가 원하는 기술.. 내가
원하는 소스를 찾아내겠다는 강한 열망이 없다면.. 당신 눈에 shutdown 이 보일
리가 없소.. 사방 천지에 깔려있는 shutdown 얘기가.. 당신 눈에만 안보인다는거요..
왜?
그만큼의 열망이 없었으니까..

소스에 대한 탐욕심을 기르시오.. 아니.. 이건 기른다고 길러지는게 아니지만..
남이 잘 만든 정말 예술과도 같은 소스코드들에 대한 탐욕심이 생길 정도의 불끈한
열망을 갖고 도전하지 않는다면.. 평생 당신은 남에게 물어봐야 문제를 해결할 수
있는 인간에서 벗어날 수 없을꺼요..

왜?

프로그래밍 시작한지 18년.. 그것도 C 언어만.. 근데, 아직도 본인도 난제들을 접하고
있소.. 시발 18년이 지났는데도 불구하고.. 여전히 경험하지 못한 난제들과 상황들을
대면서하면서 살고 있소.. 여전히 그걸 극복하고 있고.. 그런데, 이제는 솔직히 나이를
먹으니 한계를 느끼고 있소.. 내려놔야 하는지.. 이 집착을.. 이 번뇌를.. 내려놔야
할런지 고민을 하고있소.. 왜?
C 언어에 어셈블리를 뼈속까지 마스터했는데..? 왜? 아직도 난제가 많겠소?

"그것이.. 프로그래머의 운명이요.."

항상..

"산을 하나 넘었더니 또 산이 나타나는 직업, 그것은 프로그래머.."

질문자 당신이 눈에 보이지 않는 정보는 당신이 그만큼 성장하지 못한 척도이고..
지금 이 문제 뿐만이 아니라 또 다른 곳에서 또 다른 문제를 또 만나게 될 것이오..
아니..
영원히 계속 그런 문제들 속에서만 살 거요..
그럼, 어떻게 그런 난관들을 해처나갈꺼요? 질문?
방금 내가 위에 왜 그렇게 많은 글을 썼겠소?
당신의 질문에 대답할 수 있는 고수는 당신 곁에 없소.. 아마, 앞으로도 없을꺼요..
당신이 고수가 되지 않는 이상은..

결국.. 극복하는 자세만이 살길이고.. 끊임없는 삽질과 공부를 반복해야 하오..
끊임없는 문제에 봉착하고 끊임없이 해결하고.. 그게 한 10년에서 15년 이상되면
그때 좀 똥좀 닦겠구나.. 생각이 들꺼요..
본인도 18년이나 했는데.. 이제 똥싸고 똥닦고 물내리고 일어섰소..
근데.. 다리에 쥐가 나는구료..

어느새.. 세월은 가고.. 수중엔 남은 것도 없고.. 통닭집이나 차려야 할 상황이 드디어
왔소..

어디 좋는 통닭집이나 좀 알아봐 주시구료..

개같은 대한민국의 현실이오..

극복할 자세가 되어있지 못하다면.. 통닭집 차릴 자세가 되어있지 못한다면..
프로그래머하지 말고 다른거나 하시오..

뭐, 왠만하면 그냥 자바 프로그래머를 하시던지.. 그나마 좀 늦게 통닭집을 차리게 될테지만..
쥐가나는데 좀 더 많은 시간이 걸릴테니까..

P.S: 인간은.. 다 알면.. 재미를 잃습니다.. 모를때가 가장 재밌죠.. 아는게 약이 아니라..
독이되는 것은.. 다 알면.. 재미를 잃기 때문임.. 실증.. 권태기..
무엇보다도.. 시발 아직도 가야할 길이 멀다는 것이 절망감으로 온다는 거..
x86 CPU 마스터하면.. x64 를 해야할지는 아무도 몰랐고 x64를 해야할때 ARM CPU 를
마스터해야할 상황이 올 거라는 것을 아마도 얘기해주지 않는 분야가 이 분야요..
기술은 항상 계속해서 끊임없이 발전한다는거.. 단순히 지식만 습득해봐야 당신은
일회용품에 지나지 않는다는거.. 아무리 시스템에 대한 모든 전반적 지식을 다 습득해봐야
당신이 수학자가 아니면 넘지 못하는 산이 나온다는거.. 이해되나?
뭔말인지..? 아무리 프로그래머로 날고기어도.. 결국, 전자공학도의 지식경계선에서 멈춰
설 수 밖에 없는 것이 절망이고, 수학자의 지식경계를 넘지 못해서 경험하는게 절망이오..
근데, 시스템에 대해서 다 느끼고 몸이 동화되어 이해할 정도가 되면.. 만족하는게 아니라..
더 발전하고 싶은게 인간이오.. 그리고, 한국에서는 시스템 프로그래머가 이 이상으로
크지도 못하고.. 만약, 다시 어렸을 적으로 돌아간다면.. 수학을 하고 싶고.. 전자공학부터
시작하고 싶소.. 수학자->전자공학->컴퓨터->CPU(다양)->어셈블리->C->기타등등언어
순서가 가장 이상적인 순서요.. 그러나, 대부분은 이렇게 이상적 순서로 마스터가 된 자가
국내에는 한명도 없을 것이오.. 그게 바로 경계선이라는 거요..
경계선..
수학(?) 10년을 해도 모자를 것이고, 전자공학(?) 나이 60대가 될 때까지 해도 정복하지
못하는 분야외다..(진공관->트랜지스터->IC->Programable Chip) 아직도 계속 발전하고 있고..
어셈블리(?) C(?)
전부 한분야씩 10년을 해도 마스터링할 수 있는게 아니오.. 언어는 언어만 안다고 할 수
있는게 아니라 주변환경(그 분야의 라이브러리 생태계, 그 분야 코드 리소스의 전반적인
펼쳐져있는 상황)을 마스터하지 못하면 단순 문법마스터한다고 되는게 아니기 때무넹..
실제 영어나 일본어나 중국어나 그 나라의 문화를 사랑하고 관심을 가지 않으면 실력이 늘지
않는다는 현실세계와 언어적 속성이 똑같소..
근데, C 언어 하나는 그래도 남 부럽지 않을 만큼 할 수 있지만.. 그게 18년 간의 일이었고..
결국엔 한계를 만났소.. 이제 목숨을 걸지는 말자라는.. 절망감..(?)
이정도를 해도 주변에서 다들 고수라는 소리는 할지언정 절대 구루라는 소리는 못듯소..
한 분야만 정복한다고 듣는 소리가 구루가 아니기 때문에..
최초 질문자는 질문을 하는 버릇 대신에 먼저 즐기기를 바라오.. 소스 탐욕심이 생길 정도로..
그럼, 이런 게시판에 쓰레기 댓글 다는 인간들을 처볼 일이 없을 것이오..
내 글이 쓰레기 처럼 보인다면..
그것도 당신의 능력중에 하나이니.. 뭐라하지는 않겠소.. 어차피, 시간은 흘러갈 것이니까..
성장한 후에 읽어보면 또 다를 것이니까.. 진실은 가려지지 않소.. 다만, 배척 당할 수는 있지요..

고생들 하시구료.. 이 개같은 세상에.. 프로그래머로 활약하는 당신들.. 뭐 실력여하를 떠나서..
당신들은 행복과 불행을 동시에 소유한 자들이니..
세상을 탓하시구료..

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 수, 2013/04/03 - 7:51오전

좀 가르쳐주면 니가 틀린게 없는지 좀 먼저 돌아봐라..

shutdown() 맨날 해바라 븅신아 time_wait 안생기나.. ㅋㅋ

클라이언트측에서 액티브 클로즈를 해서 time_wait 를 안만들게 설계하는게 관건이지...

좀 나이 쳐먹은거 같은데 영... 이래서 대한민국이 이지경이라니깐 쩝..

수고.

한국도 좀 나이값 하는 사회가 왔으면 한다. 대접만 받으려고 하지말고.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 수, 2013/04/03 - 7:57오전

아마 FIN 을 나눠서 보내는 시간차로 인해서 time_wait 이 니 눈에 보인 시간이 바뀌어서 착각하고 있는것일게다.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 수, 2013/04/03 - 8:10오전

처음부터 니놈 말투가 짜증나서 나도 오직 너한테 이렇게 답글달고 있다만...

shutdown() 에 대해서 테스트나 해보고 그다음에 장을 지지던지 자결하던지 니맘대로 하세요

pak2536의 이미지

글쓴이: pak2536 / 작성시간: 수, 2015/01/07 - 2:57오후

리눅스 커널 소스 코드를 보면 내가 소켓을 종료하면서 TIME-WAIT가 아닌 CLOSE 상태로 바로 넘어가려면 결국 RST를 날려야 됩니다. 이렇게 되면 gracefully close가 아니고 말 그대로 연결이 중단된걸로 보면 됩니다.

RST는 연결을 종료할 당시 (보통 close) 소켓 수신 버퍼에 안 읽은 데이터가 있으면 날리고 그 외의 경우엔 FIN을 날립니다. FIN이 날라가면 무조건 TIME-WAIT에 간다고 보면 됩니다. (이건 TCP state 를 보면 당연히 아실겁니다.)
윗 분 말씀대로 FIN을 수신해야지 TIME-WAIT가 안남으며, 이게 영 마음에 안든다면 linger를 조절하거나 linux 값 중에 net.ipv4.tcp_max_tw_buckets 변수가 있습니다. 이걸 줄이면 됩니다. 물론 이 값이 적으면 dmesg에 소켓 메모리가 없어서 어쩌구저쩌구 내용이 뜨는데, 이건 알아서 무시하시길. 그런데 TW 소켓은 원래 ACK에 대한 ACK가 없는 TCP 태생의 문제 때문에 만들어진 거라서, 최소 몇 초는 유지하는게 도움이 될 겁니다.

substances의 이미지

글쓴이: substances / 작성시간: 화, 2019/02/12 - 3:13오후

지나가다가 들립니다..

ActiveClose쪽에서 TIME_WAIT이 발생이 안하려면 linger옵션을 이용해서 AbortionClose하시면 TIME_WAIT없이 바로 비정상종료 할 수 있습니다..(onoff= 1, timeout= 0 ) 다만 비정상종료이기 때문에 TIME_WAIT이 네트워크 상의 여러가지 상황(지연/유실)에 대한 안정성을 보장해주지 못하게 되겠죠. 이런 걸 감안한다면 linger로 option주시고 close해주시면 됩니다....

substances의 이미지

글쓴이: substances / 작성시간: 화, 2019/02/12 - 3:33오후

클라이언트에서 close를 요청하는 것이라면
클라이언트 closesocket() 전에 linger옵션 활성화 해주시면 되겠습니다.

ActiceClose -> Close() 요청한 쪽을 말하는 것입니다.
TIME_WAIT은 ActiceClose쪽만 빠지게 됩니다. (물론 네트워크 특성상 둘 다 동시에 빠지는 경우도 있지만...)
필요한 쪽에 linger옵션으로 비정상종료 해주시면 TIME_WAIT 제거 할 수 있습니다

substances의 이미지

글쓴이: substances / 작성시간: 화, 2019/02/12 - 3:41오후

이미 오랜 시간이 지나서 답을 찾으셨을거라 생각하지만, ( @arimae님이 이미 답해주셨고, 코드까지 작성해주셨네요! )
또 같은 질문을 하고 있을 누군가를 위해서 남깁니다..
저도 잘 모르지만 아는 선에서 답해보았습니다....

댓글 달기

텍스트 포맷에 대한 자세한 정보

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.