글쎄요.. connect의 리턴 시점은 connect함수가 syn, mss를 보내고 서버측에서 accept함수가 syn, ack, mss 를 보낼때 이걸 받아야 리턴하는 것으로 알고 있는데.
(물론 에러경우 재전송 횟수 초과일때이겠죠.)
서버의 패킷이나 클라이언트의 패킷이 노이즈 등으로 변질될 가능성도 있고 유실될 수 있다고 생각하는데요...
일반적인 경우 에크가 없으면 발신 측에서 재전송을 하기때문에 패킷 유실이 없는 것 처럼 보이는 게 아닐까요..???
tcp의 모든 전송은 재전송 타이머를 돌리기 때문에 소켓 옵션을 조절해서 재전송 타이머의 시간을 줄일 수 있다고 생각해서. 답을 올렸는데 생각해보내 recv나 send이외의 경우 재전송 타이머 시간을 조절해 본적이 없어 connect에서의 재전송 시간을 바꿀수 있을지는 확신이 않서는군요.
생각해 볼 문제군요.(테스트 해볼 문제인가..???)
<추가부분입니다.>
실제 커넥트 호출후 패킷을 필터링해서 패킷 하나만 없애버리고(고의적으로 유실) 이후는 필터링 안했습니다.
블럭모드에서는 정상적으로 connect가 리턴해서 세션이 맺어 졌고 넌 블럭으로 만들경우 세션을 맺지 못하는 군요.
connect에서 재전송 타이머는 setsockopt로 해결하지 안는군요... recvmsg, sendmsg류의 함수에만 영향을 준다고 스티븐아저씨가 써놨군요. 대신 siglongjmp를 사용하는 방법을 제시하는 군요...
정말 connect에 setsockopt이 안먹을지... 시간되는데로 테스트해보고 글올리져..
Do you think that's the air you are breathing now?
TCP/IP 통신에서는 패킷 유실이 없습니다. 패킷이 노이즈등에 의해 변질될 가능성에 대해 의심하는것은 시스템콜 부분에서 생각하실 부분이지 에플리케이션에서 생각할 부분은 아닙니다. 제가 생각하기에 지금 제작하시는 분은 CONNECT부분이 잘 않되셔서 그러신것 같은데 이 주제와는 전혀 다른것 같습니다. 하여간 에플리케이션 레이어에서 패킷 유실은 전혀 고려의 대상이 아닙니다. TCP/IP를 에플리케이션에서 고려할 부분은..
1. 절대 데이터 유실이 일어나지 않는다.
2. 하지만 언제 그 데이터가 전송될지는 모른다.
이정도입니다. 따라서 데이터 송수신시 원하는 데이터의 크기를 보내주고 받는 정도의 처리만으로 충분히 데이터 송수신이 원활하게 이루어질수가 있습니다.
그럼 다시 CONNECT 문제로 되돌아 가서... 예전에 제가 올려 놓은것 한번 보시면 대충 해결하실수 있을겁니다. 뭐 거창한거는 아니고 모두가 사용하는 그런 방법입니다.
CONNECT시 상대방 서버가 응답하지 않을 경우 경우에 따라서는 하세월일 경우가 많을겁니다. 데이터 송수신시에는 블락인지 넌블락 모드인지는 본인이 에플리케이션 특성에 맞게 조정하시면 되지만 CONNECT시에만은 잠시동안 넌블락 모드로 맺어야만 이유없이 블락 당하는 결과를 방지하실수 있을겁니다.
다만 넌블락 모드로 CONNECT시도 할때에는 리턴값이 당연히 에러로 나옵니다. 이럴때는 리턴값이 아닌 에러값을 가지고 판단해야 합니다. 이중에 EINPROGRESS를 체킹하고 EISCONN로 확인 하시면 됩니다. 이때 재 접속 시도를 하실건지 아닌지등 무한루프 안에 SELECT를 통해 확인하시면 될겁니다.
이것은 플렛폼마다 조금씩 다르기 때문에 조금씩 맞추어 사용하셔야만 할겁니다. HP/AIX/LINUX등 아주 아주 조금씩만 다릅니다. 하지만 대충 비슷하다고 생각하시면 될겁니다.
패킷의 정합성 검사는 시리얼 통신이나 UDP의 경우에 하지만 TCP/IP의 경우에는 은행 시스템의 경우에는 거의 하지 않습니다. 은행시스템의 경우 특정 데이터 필드들의 경우 중간에 다른쪽에서 변조할 가능성 때문에 몇몇 부분을 정합성 검사를 하긴 하지만 통신구간상에서 하는것은 없습니다.(제 경험에서는요) 다른 금융시스템(선물/옵션쪽 국내 증권전산쪽 데이터는 원래가 UDP래서 하지만 해외쪽 데이터에서는 CRC가 붙어 나오기도 하고 아니기도 하고 대중없습니다. 하지만 대체적으로 않합니다. )에서도 CRC데이터가 붙어 가거나 하는 부분이 존재하긴 하지만 실제 데이터 검사는 않하는 편입니다.
대부분 non-blocking 소켓으로 해결하시더군요. Stevens 책
대부분 non-blocking 소켓으로 해결하시더군요. Stevens 책에 기법이 자세히 나와있습니다.
connect()에 timeout을 넣기 위해서 connect() 전
connect()에 timeout을 넣기 위해서
connect() 전에 소켓을 non-blocking 소켓으로 바꿨다가 connect() 후에
다시 blocking 소켓으로 바꾸어도 제대로 동작하나요?
왔다갔다 하는 예제도 그책에 있습니다.
왔다갔다 하는 예제도 그책에 있습니다.
non blocking....
넌 블럭으로 할경우 패킷유실에 의해 문제가 생길것 같은데요. 재전송 타이머를 줄이는게 이런 문제를 유발하지 않을것 같은데....
Do you think that's the air you are breathing now?
어떤 패킷 유실일까요? select 류로 제대로 처리하면 유실될 이유가
어떤 패킷 유실일까요? select 류로 제대로 처리하면 유실될 이유가 있습니까? connect 의 타임아웃을 조절할 이식가능한 방법이 있습니까? 궁금합니다.
Re: non blocking....
유실될 일이 없다고 아뢰오.
걱정하지 않으셔도 됩니다. :D
------------------ P.S. --------------
지식은 오픈해서 검증받아야 산지식이된다고 동네 아저씨가 그러더라.
걱정하지 마세요.
다른분이 대답해주신 부분도 많고요 제가 예전에 올렸던것도 있습니다. 한번 참조해보세요.
http//bbs.kldp.org/viewtopic.php?p=89949&highlight=#89949
http//bbs.kldp.org/viewtopic.php?p=71222&highlight=#71222
를 한번 보시고요..
넌블락이던 블락이든 데이터 유실의 경유는 발생하지 않습니다. 대신 프로그램을 그에 맞게 작성 하시면 될겁니다. 즐거운 하루 되세요.
패킷유실이 없다???
글쎄요.. connect의 리턴 시점은 connect함수가 syn, mss를 보내고 서버측에서 accept함수가 syn, ack, mss 를 보낼때 이걸 받아야 리턴하는 것으로 알고 있는데.
(물론 에러경우 재전송 횟수 초과일때이겠죠.)
서버의 패킷이나 클라이언트의 패킷이 노이즈 등으로 변질될 가능성도 있고 유실될 수 있다고 생각하는데요...
일반적인 경우 에크가 없으면 발신 측에서 재전송을 하기때문에 패킷 유실이 없는 것 처럼 보이는 게 아닐까요..???
tcp의 모든 전송은 재전송 타이머를 돌리기 때문에 소켓 옵션을 조절해서 재전송 타이머의 시간을 줄일 수 있다고 생각해서. 답을 올렸는데 생각해보내 recv나 send이외의 경우 재전송 타이머 시간을 조절해 본적이 없어 connect에서의 재전송 시간을 바꿀수 있을지는 확신이 않서는군요.
생각해 볼 문제군요.(테스트 해볼 문제인가..???)
<추가부분입니다.>
실제 커넥트 호출후 패킷을 필터링해서 패킷 하나만 없애버리고(고의적으로 유실) 이후는 필터링 안했습니다.
블럭모드에서는 정상적으로 connect가 리턴해서 세션이 맺어 졌고 넌 블럭으로 만들경우 세션을 맺지 못하는 군요.
connect에서 재전송 타이머는 setsockopt로 해결하지 안는군요... recvmsg, sendmsg류의 함수에만 영향을 준다고 스티븐아저씨가 써놨군요. 대신 siglongjmp를 사용하는 방법을 제시하는 군요...
정말 connect에 setsockopt이 안먹을지... 시간되는데로 테스트해보고 글올리져..
Do you think that's the air you are breathing now?
흠..
안녕하세요.
TCP/IP 통신에서는 패킷 유실이 없습니다. 패킷이 노이즈등에 의해 변질될 가능성에 대해 의심하는것은 시스템콜 부분에서 생각하실 부분이지 에플리케이션에서 생각할 부분은 아닙니다. 제가 생각하기에 지금 제작하시는 분은 CONNECT부분이 잘 않되셔서 그러신것 같은데 이 주제와는 전혀 다른것 같습니다. 하여간 에플리케이션 레이어에서 패킷 유실은 전혀 고려의 대상이 아닙니다. TCP/IP를 에플리케이션에서 고려할 부분은..
1. 절대 데이터 유실이 일어나지 않는다.
2. 하지만 언제 그 데이터가 전송될지는 모른다.
이정도입니다. 따라서 데이터 송수신시 원하는 데이터의 크기를 보내주고 받는 정도의 처리만으로 충분히 데이터 송수신이 원활하게 이루어질수가 있습니다.
그럼 다시 CONNECT 문제로 되돌아 가서... 예전에 제가 올려 놓은것 한번 보시면 대충 해결하실수 있을겁니다. 뭐 거창한거는 아니고 모두가 사용하는 그런 방법입니다.
CONNECT시 상대방 서버가 응답하지 않을 경우 경우에 따라서는 하세월일 경우가 많을겁니다. 데이터 송수신시에는 블락인지 넌블락 모드인지는 본인이 에플리케이션 특성에 맞게 조정하시면 되지만 CONNECT시에만은 잠시동안 넌블락 모드로 맺어야만 이유없이 블락 당하는 결과를 방지하실수 있을겁니다.
다만 넌블락 모드로 CONNECT시도 할때에는 리턴값이 당연히 에러로 나옵니다. 이럴때는 리턴값이 아닌 에러값을 가지고 판단해야 합니다. 이중에 EINPROGRESS를 체킹하고 EISCONN로 확인 하시면 됩니다. 이때 재 접속 시도를 하실건지 아닌지등 무한루프 안에 SELECT를 통해 확인하시면 될겁니다.
이것은 플렛폼마다 조금씩 다르기 때문에 조금씩 맞추어 사용하셔야만 할겁니다. HP/AIX/LINUX등 아주 아주 조금씩만 다릅니다. 하지만 대충 비슷하다고 생각하시면 될겁니다.
패킷의 정합성 검사는 시리얼 통신이나 UDP의 경우에 하지만 TCP/IP의 경우에는 은행 시스템의 경우에는 거의 하지 않습니다. 은행시스템의 경우 특정 데이터 필드들의 경우 중간에 다른쪽에서 변조할 가능성 때문에 몇몇 부분을 정합성 검사를 하긴 하지만 통신구간상에서 하는것은 없습니다.(제 경험에서는요) 다른 금융시스템(선물/옵션쪽 국내 증권전산쪽 데이터는 원래가 UDP래서 하지만 해외쪽 데이터에서는 CRC가 붙어 나오기도 하고 아니기도 하고 대중없습니다. 하지만 대체적으로 않합니다. )에서도 CRC데이터가 붙어 가거나 하는 부분이 존재하긴 하지만 실제 데이터 검사는 않하는 편입니다.
즐거운 하루 되세요.
댓글 달기