아래 글은 김영대님의 홈(http://board.member.cgiserver.net/CrazyWWWBoard.cgi?db=cozykyd02b)에서 퍼온글입니다.



저도 제 프로젝트에서 소켓을 사용한 다중 송수신 프로그램 작성시 패킷의 크기를

결정하는 데에 참조한 글입니다.



////////////////////////////////////////////////////////////////////////////////

정윤옥님의 글

---------------------------

Socket통신시 받아들이수 있는 최대 데이타의 길이는 한정되어 있는지 가르쳐 주세요

한정되어 있다면 받아들일수 있는 최대 데이타의 길이는 얼마나 됩니까?

---------------------------



안녕하세요 김영대(cozy@hanmail.net)입니다



소켓의 데이터 전송크기는 원칙적으로 말한다면 제한이 없습니다 (?)

우리가 보통 애기하는 TCP/IP 프로토콜중 IP 가 실제 데이터를 실어 날으는

프로토콜인데 이 프로토콜은 IP 데이터그램(IP 계층의 전송단위)의 크기보다 튼

자료를 송,수신 한다면 내부에서 일정한 크기고 잘라서 보내고 받을때는 다시

몇개의 데이터그램으로 잘라진 데이터를 조합하여 사용하게 됩니다



우리가 보통 사용하는 소켓 함수중 send(), recv() 함수를 예를 든다면

send(10000 바이트) 를 했을때 IP 데이터그램이 한번에 1000바이트씩 보낼 수

있다면 1000 바이트씩 10번에 나뉘서(내부적으로) 보내게 되고 받는쪽에서는

10번이상(송신상에 에러가 없었다면 10번) 받아서(내부적으로) 조합하여 최종

사용자에겐 10000바이트를 주게 됩니다



또한 Send(10000 바이트) 하게되면 10000 바이트를 상대방(peer)에게 곧바로 보내는것이

아니라 다만 소켓이 송신할 데이터를 내부적으로 사용하는 PC의 송신버퍼에 복사하는

동작만 합니다... 그러면 송신 버퍼에 있는 10000바이트를 IP데이터그램으로 쪼개서 순차적으로

보내게 됩니다

그러므로 상대방도 Recv(10000바이트)하여 10000바이트를 바로 수신하는것이 아니라

사용하는 PC의 수신버퍼(수신된 데이터가 있다면)에 저장되어 있는 데이터를 사용자

프로그램 영역으로 읽어 들이는 동작을 합니다



정리한다면 사용자가 10000바이트를 상대방에게 send(10000바이트) 하면 그 즉시

PC의 송신버퍼에 저장하고 내부적으로 이 저장된 데이터를 IP데이터그램으로 쪼개서

송신을 시작합니다

데이터를 받는 상대방은 마찬가지로 쪼개진 IP데이터그램을 받아서 수신버퍼에 계속

쌓아두었다가 recv()함수를 호출하면 쌓아둔 데이터중 recv()시 지정한 읽을 바이트수만큼

꺼내서 주는 것입니다



그래서 프로그램상에서 사용하는 송,수신 크기는 별 의미가 없다는 것이죠

송,수신 성능은 내부에서만 동작하는 IP 데이터그램의 크기에 달려있다는 것입니다

결론적으로 MTU(Maximum Transfer Unit) 의 크기에 달려있습니다

MTU는 IP프로토콜이 한번에 전송할 수 있는 최대의 IP데이터그램 크기를 의미합니다

이론상 IP데이터그램의 최대 크기는 65536바이트 입니다

그러나 실제로는 IP 프로토콜의 데이터 전달 경로가 되는 선로의 종류에 따라 최대로 전송할 수

있는 데이터그램의 크기가 결정됩니다



가장 많이 사용되는 LAN 프로토콜인 이더넷의 경우 하드웨어적으로 데이터의 크기가 1500바이트

까지 허용되며, 직렬 포트 상에서 PPP 프로토콜을 사용하는 경우에도 1500바이트 입니다

또한 이전에 많이 사용했던 SLIP은 대부분 576바이트 입니다



그래서 이 MTU값을 에러가 거의 없는 선로에서는 크게 하는 것이 프로토콜 헤더로 인한

오버헤드를 줄이는 방법입니다

하지만 에러가 많은 선로의 경우에는 한 번 에러가 발생할 때 큰 데이터를 잃게 되어 손해보는

것도 크기 때문에 선로의 전송 품질에 따라 적당한 MTU 값을 택하는 것이 필요합니다

(일반적으로 이 MTU값은 TCP/IP 프로그램의 사용자가 결정하는 사항이 아니고, 선로나

시스템 환경에 의해 자동적으로 결정됩니다)

인터네트상에 보면 PC의 최적의 MTU값을 찾아주는 유틸리티가 있습니다

송기원 wrote:

> 소켓을 이용한 파일송/수신 컴포넌트의 베타버젼을 현재 테스트 중입니다.

>

> 근데..제가 맹근 파일송/수신 컴포넌트가 아주 이상적이진 못하지만..

> 제가 테스트한 결과로는 20MB짜리 파일 송/수신에서도

> 아무런 하자 없이 잘 동작을 합니다...

> 물론 양방향에서 Flow Control, Timer Out Control까지 지원을 하구요..

> 근데.....

> 맹글긴 맹글었는데...

> 저나름데로의 의문점이 생기는 군요..

>

> 제가 테스트 한바로는 4096Byte단위로 쪼개어서 자료를 송/수신 처리

> 하면 문제가 별루 없는데...4096Byte이상의 자료를 송/수신시에는

> 100% Data Loss가 발생을 하는 군요....

> 왜 Data Loss가 생길까요..?? 이 원인만 알면 좀더 개선된 파일송/수신 컴포

> 넌트를 맹글 수 있을것 같은데..

> 현재로서는 제가 원인을 모르니..대책을 세울수가 없네요...

> 웹 브라우져로(HTTP Protocol)로 파일을 송/수신할경우에는 암만봐도

> 수신쪽에서 Data Loss가 발생을 안 하는데...

> 왜 델파이의 TserverSocket과 TclientSocket에서는 데이타의 손실이

> 발생을 하는지...??

> 이글을 읽으시고 혹시

> Data손실의 원인이나 이유를 아시는 분은 답변을 꼭~ 부탁드립니다.

>

>



안녕하세요.

정확한 답이 되지는 못 할것 같지만 나도 비슷한 경우가 있었어서 알려드립니다.

화일의 사이즈가 커졌을때는 data의 Loss율이 커진다고 하셨는데

음... 화일을 받고 있는 도중에 Server쪽에나 아니면 다른 Client쪽에 송/수신 중인지

아니면 Timer메시지가 발생중인지를 한번 체크해 보시지요.

화일의 사이즈가 커지면 화일을 Down중에 다른 Message들로 인해 Stream에서 한번에

받기가 힘들더라구요. 제 경험상..

하여튼 이렇게 되서 해결되면 다행이지만 그래도 안되면 어쩔지 저의 아는 한도에서

알려드립니다. 그럼 이만. 그리고 위에 질문한 내용좀 아시면 답 좀 해주세요.

> 안녕하세요.

> 정확한 답이 되지는 못 할것 같지만 나도 비슷한 경우가 있었어서 알려드립니다.

> 화일의 사이즈가 커졌을때는 data의 Loss율이 커진다고 하셨는데

> 음... 화일을 받고 있는 도중에 Server쪽에나 아니면 다른 Client쪽에 송/수신 중인지

> 아니면 Timer메시지가 발생중인지를 한번 체크해 보시지요.

> 화일의 사이즈가 커지면 화일을 Down중에 다른 Message들로 인해 Stream에서 한번에

> 받기가 힘들더라구요. 제 경험상..

> 하여튼 이렇게 되서 해결되면 다행이지만 그래도 안되면 어쩔지 저의 아는 한도에서

> 알려드립니다. 그럼 이만. 그리고 위에 질문한 내용좀 아시면 답 좀 해주세요.

>

>

OnRead Event에서 저의 경우에는 전역버퍼를 설정하여 계속하여

전역버퍼에 들어온 데이타를 누적시킵니다..

그럼..희선님의 설명되로라면...OnReadEvent가 정상적으로

동작하지 않는다는 말씀인데...

그럼..이건 델파이의 버그인가요....????????

송기원 wrote:

> > 안녕하세요.

> > 정확한 답이 되지는 못 할것 같지만 나도 비슷한 경우가 있었어서 알려드립니다.

> > 화일의 사이즈가 커졌을때는 data의 Loss율이 커진다고 하셨는데

> > 음... 화일을 받고 있는 도중에 Server쪽에나 아니면 다른 Client쪽에 송/수신 중인지

> > 아니면 Timer메시지가 발생중인지를 한번 체크해 보시지요.

> > 화일의 사이즈가 커지면 화일을 Down중에 다른 Message들로 인해 Stream에서 한번에

> > 받기가 힘들더라구요. 제 경험상..

> > 하여튼 이렇게 되서 해결되면 다행이지만 그래도 안되면 어쩔지 저의 아는 한도에서

> > 알려드립니다. 그럼 이만. 그리고 위에 질문한 내용좀 아시면 답 좀 해주세요.

> >

> >

> OnRead Event에서 저의 경우에는 전역버퍼를 설정하여 계속하여

> 전역버퍼에 들어온 데이타를 누적시킵니다..

> 그럼..희선님의 설명되로라면...OnReadEvent가 정상적으로

> 동작하지 않는다는 말씀인데...

> 그럼..이건 델파이의 버그인가요....????????

>

>

안녕하세요.

델파이의 버그라기보다는 윈도우 시스템의 제한성이 아닐까요.

제도 위의 답변에 대한 정확한 이유에 대하여 Debug를 할 수 없는

상태여서 문제의 원인을 정확히 꼭 집어서 말씀드리기는 힘드나

OnRead시에 다른 함수의 호출이나 Delay를 넣어보면 혹시 알 수 있지

않을까 합니다. 저의 경우도 OnRead에 화일을 받는 부분 말고 다른

루틴을 추가 하였을시에는 올바르지 않은 데이타(깨짐?)가 들어 오는

것을 알았습니다.

그래서 저도 이런 루틴을 없애거나 다른 방법을 취했죠.

그리고 Timer 메시지가 발생하는 경우도 그렇습니다.

그러한 원인에 대한 이유는 윈도우의 내부 시스템 사정인것으로 더

연구해 보면 알수도 있겠지만 지금까지는 저도 그이유를 모르겠습니다.

이상 저의 보잘것 없는 경험을 얘기해 드렸습니다.