현재 위치

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

TCP/IP 에서 timeout 체크

heoks의 이미지
글쓴이: heoks / 작성시간: 월, 2005/12/19 - 4:30오후

connect 연결 후에 client에서 server에게 인증코드를 보냅니다.
server에서는 받았다는 ack를 건네주고 인증코드를 검사해서 승인/비승인 등의 내용을 Client에게 보내주게 됩니다.

여기서, Client가 처음에 인증코드를 Server에게 보낸 후에
무한정 기다릴수가 없기 때문에 timeout을 걸어서 다시금 인증코드를 보내게 하려고 합니다.

궁금한 것이 있는데요.
connect를 한 후, send 했을때 에러가 나지 않았다면
그 내용은 보내진 것이다라고 확신할 수 있는 것인가요?
저는 그렇게 알고 있는데... 확인을 해야한다고 합니다(~~~).

즉, 위의 경우에서 인증코드를 보낸후에는 다시 보낼 필요가 없지 않나요?

socket timeout 으로 검색을 해보았는데 connect 할때의 문제이지 연결이 된 후에는 보낸 데이터에 대해서 다시 보내거나 하지는 않는것 같은데요. 앞선 선배님들의 조언 기다리겠습니다.

Forums: 
프로그래밍 QnA
익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2005/12/19 - 4:47오후

TCP이고, 웹(http 1.0)처럼 매번 세션을 다시 맺는 경우가 아니라면(한번 연결맺고 계속사용하는 )라면 절대 다시 보낼 필요가 없습니다.

* 단, 엄청나게 고도의 보안을 요하는 것(?)이라서, 매 메시지(tcp내에서 정의된)별로 인증을 하는 정도의 엄격하고도 엄격함이 필요하다면, 심지어 1초늦게 오면 다시 인증한다던지 등등이라면, 재전송에 타임아웃을 구현하는 방법도 있을 수는 있겠습니다. (이렇게 까지 구현하는 사이트가 1개라도 있는지 궁금?!)

* 단, UDP를 사용한다면, 인증코드 보내고 타임아웃 걸고 그런 작업을 해야겠지요. 또는, TCP인데,웹(http 1.0)프로토콜처럼 동작한다면, 매번 세션을 새로 맺게 될 것이므로, 인증을 타임아웃에 의해 재시도 하는 것이 필요할 수 있습니다.

heoks의 이미지

글쓴이: heoks / 작성시간: 월, 2005/12/19 - 5:04오후

감사합니다. 이부분에서 manager와 저와 다른 개발자들하고 논란이 있었거든요.

"응용프로그램 차원에서 send 하고 난 후(send시 error 없음)에 TCP/IP 인 경우 재전송할 필요는 없다"

는 것이지요?

아...... 시원하네요. 이젠 복수의 시간이 8) 8) :twisted: :twisted:

다시 감사드립니다.

hyperhidrosis의 이미지

글쓴이: hyperhidrosis / 작성시간: 월, 2005/12/19 - 8:12오후

Quote:

"응용프로그램 차원에서 send 하고 난 후(send시 error 없음)에 TCP/IP 인 경우 재전송할 필요는 없다"

저도 항상 궁금한 부분입니다.
send() 성공은 과연 어디까지 보장하는것일까요?
만일 저쪽에서 성공적으로 받았다는것을 보장한다면... 말이 안됩니다.
그러면 너무 늦습니다...
만일 보장이 된다면, 1000바이트데이타를 보낼때
1000바이트를 한번에 보내는것보다
1바이트씩 1000번 나누어 보내는것이 훨씬(엄청) 느리다는 의미가
됩니다..
익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 월, 2005/12/19 - 9:23오후

send 의 성공은 커널단의 소켓버퍼로의 복사 성공이냐 실패입니다.
물리적인 전송이 완료된 것과는 다른얘기죠.

spacelee의 이미지

글쓴이: spacelee / 작성시간: 화, 2005/12/20 - 12:13오전

위에분 말씀대로 send 성공은 OS 소켓버퍼로의 복사까지만 하고 리턴합니다.
상대방이 받을 수도 있고, 못받았을 수도 있습니다.

보내는 쪽에서 상대방이 받았다는 확신을 가져야 하는 애플리케이션 로직이라면
상대방이 reply를 던져주는 구조로 프로토콜을 만드시는 것이 좋습니다.
그리고 소켓 close할때 linger 옵션에 관해서 잘 처리하셔야 되구요.

그런데?
상대방 역시 송신하는 내가 reply를 확실히 받아야 하는걸 확실히 알아야
진행할 수 있는 로직이라면?
다시 re-reply를 던져줘야 하느냐하는 루프에 빠지게 됩니다.
사실상 네트웍에서는 그런 문제가 무한루프 돌게 됩니다.

즉 네트웍에서는 100% 확신을 가지고 진행하게 하기는 불가능 합니다.
그래서 tcp를 best-effort 프로토콜이라고 하죠.
(tcp의 3-way handshake, 4-way close 모두 100% 완벽한
프로토콜은 아닙니다.)

네트웍에서 프로토콜의 확실성 문제는 어느 정도로 확실하게 진행하게 하느냐 하는 '정도'의 문제로 귀착됩니다.
결국 위에처럼 application 상에서 한번 reply 던지는 정도가 가장 효율적인
타협점이 아닐까 싶습니다.

권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -

GENIUS의 이미지

글쓴이: GENIUS / 작성시간: 화, 2005/12/20 - 5:17오전

참오래 간만에 글을 올립니다.

tcp/ip 프로그램에 있어서 대기 상태를 잘못 처리하면 무한정 기다리게 되지요.
이것을 방지하기 위해서
select()
문을 사용합니다.

select()
FD_SET(fd,&readfds);
FD_CLR(fd,&readfds);

TCP/IP 책을 보면 알수 있을 것 입니다.

select 문에 timeout 을 설정함면 수신이 없는 경우 송신 접속이 끊어진 경우 재접속 등등을 구현 할수 있습니다.

서점에서 책을 찾아 보세요.

리눅스 네트웍 개발 (FA) /유비쿼터스 네트웍 하드웨어 개발 프로젝트 진행/인터넷을 통한 원격제어/
리눅스 베이스 FA 구현/초소형 무선랜 모듈개발 진행중/리눅스 웹 통합시스템 구축

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 화, 2005/12/20 - 9:19오전

spacelee wrote:
즉 네트웍에서는 100% 확신을 가지고 진행하게 하기는 불가능 합니다.
그래서 tcp를 best-effort 프로토콜이라고 하죠.
(tcp의 3-way handshake, 4-way close 모두 100% 완벽한
프로토콜은 아닙니다.)

뭔가 오해가 있으신 것 같은데, TCP 는 guaranteed service 이죠.
UDP나 IP 같은 경우를 best-effort 라고 칭합니다만.

네트웍 통신의 구조적인 문제와 프로토콜의 개념을 혼동하고 계신듯합니다.

spacelee의 이미지

글쓴이: spacelee / 작성시간: 화, 2005/12/20 - 9:39오전

Anonymous wrote:
spacelee wrote:
즉 네트웍에서는 100% 확신을 가지고 진행하게 하기는 불가능 합니다.
그래서 tcp를 best-effort 프로토콜이라고 하죠.
(tcp의 3-way handshake, 4-way close 모두 100% 완벽한
프로토콜은 아닙니다.)

뭔가 오해가 있으신 것 같은데, TCP 는 guaranteed service 이죠.
UDP나 IP 같은 경우를 best-effort 라고 칭합니다만.

네트웍 통신의 구조적인 문제와 프로토콜의 개념을 혼동하고 계신듯합니다.

tcp를 best-effort 프로토콜이라고 부르는 건 잘못됐네요.^^;;

하지만, 일반적으로 시그널,데이터 채널이 분리된 통신 방식과
그 두 개념이 없는 tcp/ip 프로토콜을 통틀어서 비교 설명할때, tcp/ip는 100% guaranted는 보장을 하지 못하기 때문에
tcp/ip의 상대적인 특성으로써 그렇게 얘기를 하기도 한다고
저희 교수님이 옛날에 그러셨더군요..^^;;
말씀하셔서 옛날 교재를 한참 뒤져 봤습니다.

권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -

heoks의 이미지

글쓴이: heoks / 작성시간: 화, 2005/12/20 - 10:26오전

send() 의 리턴이 성공이었다는 것이 당연히 수신자쪽에서 수신을 했다라는 것에 대한 보장은 아닙니다. 일단 소켓버퍼로의 복사가 성공하면 TCP 프로토콜단에서 해당하는 데이터를 책임(?)지고 전송해주는 것으로 알고 있습니다(연결이 되어있다면요). 즉, 중간에 데이터가 손실이 되거나 하게되면 다시 보내준다는 거지요. 그래서 연결이 확인된 거라면 send() 함수의 성공만으로 데이터가 전송될거라는 확신을 할 수 있지 않으냐? 라는 것이 저의 질문이었습니다.
여기서 연결이 확인되지 않은 경우는 프로토콜 단에서 할 수 있는 방법이 아니기 때문에 heart beat 같이 주기적으로 상대와 연결되어 있는지 체크를 해야하는 것으로 알고 있습니다.

spacelee 님께서 말하신 것에서 처럼
"application 상에서 한번 reply 던지는 정도가 가장 효율적인
타협점이 아닐까 싶습니다."

그래서 받았다는 것에 대한 ack를 기다리는 것입니다. 문제는 ack를 언제까지 기다려야 하는냐입니다. 저의 생각으로는 연결체크는 따로 heart beat을 하고 있기 때문에 send를 하고 난 후 에 recv() 할 때까지 그냥 기다리면 된다는 것이고 다른 사람은 timeout을 두어서 재전송 해야 한다는 것입니다.
제생각에 ack가 늦게 오는 것은 기다려야하는 문제이지 데이터를 재전송하는
문제는 아니라고 생각되거든요.
저의 생각이 맞는지, 틀리다면 어떻게 하면 좋은지 조언해 주시면 고맙겠습니다.

spacelee의 이미지

글쓴이: spacelee / 작성시간: 화, 2005/12/20 - 10:36오전

heoks wrote:
send() 의 리턴이 성공이었다는 것이 당연히 수신자쪽에서 수신을 했다라는 것에 대한 보장은 아닙니다. 일단 소켓버퍼로의 복사가 성공하면 TCP 프로토콜단에서 해당하는 데이터를 책임(?)지고 전송해주는 것으로 알고 있습니다(연결이 되어있다면요). 즉, 중간에 데이터가 손실이 되거나 하게되면 다시 보내준다는 거지요. 그래서 연결이 확인된 거라면 send() 함수의 성공만으로 데이터가 전송될거라는 확신을 할 수 있지 않으냐? 라는 것이 저의 질문이었습니다.
여기서 연결이 확인되지 않은 경우는 프로토콜 단에서 할 수 있는 방법이 아니기 때문에 heart beat 같이 주기적으로 상대와 연결되어 있는지 체크를 해야하는 것으로 알고 있습니다.

spacelee 님께서 말하신 것에서 처럼
"application 상에서 한번 reply 던지는 정도가 가장 효율적인
타협점이 아닐까 싶습니다."

그래서 받았다는 것에 대한 ack를 기다리는 것입니다. 문제는 ack를 언제까지 기다려야 하는냐입니다. 저의 생각으로는 연결체크는 따로 heart beat을 하고 있기 때문에 send를 하고 난 후 에 recv() 할 때까지 그냥 기다리면 된다는 것이고 다른 사람은 timeout을 두어서 재전송 해야 한다는 것입니다.
제생각에 ack가 늦게 오는 것은 기다려야하는 문제이지 데이터를 재전송하는
문제는 아니라고 생각되거든요.
저의 생각이 맞는지, 틀리다면 어떻게 하면 좋은지 조언해 주시면 고맙겠습니다.

얘기하시는 것이 tcp 가 맞으시다면 생각하시는대로, 또 다른분들 말씀대로 재전송을 굳이 안해도 됩니다.
timeout값이 얼마이냐의 문제는 문제를 좀 바꿔야 할 것 같은데요.
일단 양쪽 애플리케이션에서 data/ack를 못받은 경우에 대해서 대비되어 있는 에러 처리 flow가 확실히 있어야 하는게 먼저 일 것 같구요.

잘 아시겠지만, tcp를 쓰는 상황에서 커넥션을 맺은 단계에서 100% 처리하려고 하는건 네트웍 구조상 불가능하구요. 일정 시간 후 커넥션을 다시 맺어 트랜잭션을 다시 시작하는 식으로 커넥션 윗 레벌에서 에러 처리 flow에 대해서 대비를 하고 있어야 하겠죠.

그런 상황이라면, timeout값은 그 상황에서 선택적으로, 경험적으로 세팅하셔야 할 것 같은데요. 보통 컨피그로 빼고 적절히 조절해주는 게 맞을 것 같구요. 제가 질문을 잘 이해했나 모르겠네요.

그리고, 궁금한 것이 tcp를 쓰신다면 heartbeat를 굳이 쓰셔야 하는 상황이신지? socket 자체에 heartbeat 기능에 대한 옵션이 있기도 하구요. 설사 끊어졌다 하더라도 다음 데이터를 read/write할 때 그걸 detect 할 수 있으니깐 보통은 필요없지 않을까 싶은데...
애플리케이션 상황을 제가 잘 모르니...그냥 제 생각입니다.^^;;

권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -

navidad의 이미지

글쓴이: navidad / 작성시간: 화, 2005/12/20 - 11:31오전

Quote:
그리고, 궁금한 것이 tcp를 쓰신다면 heartbeat를 굳이 쓰셔야 하는 상황이신지? socket 자체에 heartbeat 기능에 대한 옵션이 있기도 하구요

socket 자체에 heartbeat 을 보내는 옵션이 있었나요? 제가 모르고 있었는 부분인것 같은데, 소개부탁드립니다. 지금껏 저도 heartbeat를 보내는 작업을 App에서 주기적으로 했었거든요.

=================================
나비아빠

spacelee의 이미지

글쓴이: spacelee / 작성시간: 화, 2005/12/20 - 11:46오전

navidad wrote:
Quote:
그리고, 궁금한 것이 tcp를 쓰신다면 heartbeat를 굳이 쓰셔야 하는 상황이신지? socket 자체에 heartbeat 기능에 대한 옵션이 있기도 하구요

socket 자체에 heartbeat 을 보내는 옵션이 있었나요? 제가 모르고 있었는 부분인것 같은데, 소개부탁드립니다. 지금껏 저도 heartbeat를 보내는 작업을 App에서 주기적으로 했었거든요.

SO_KEEPALIVE, TCP_KEEPALIVE 같은 소켓 옵션들입니다.
저두 본지가 오래되서 다시 함 찾아봤는데, keep alive 시간 세팅 부분의 유연성이 좀 떨어지네요. 보통 커널 수준의 패러미터라고 하니.. 상황에 맞춰서 잘 써야 할 것 같네요.

권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -

heoks의 이미지

글쓴이: heoks / 작성시간: 화, 2005/12/20 - 5:42오후

답변에 먼저 감사드립니다. :D

spacelee wrote:
잘 아시겠지만, tcp를 쓰는 상황에서 커넥션을 맺은 단계에서 100% 처리하려고 하는건 네트웍 구조상 불가능하구요. 일정 시간 후 커넥션을 다시 맺어 트랜잭션을 다시 시작하는 식으로 커넥션 윗 레벌에서 에러 처리 flow에 대해서 대비를 하고 있어야 하겠죠.

그런 상황이라면, timeout값은 그 상황에서 선택적으로, 경험적으로 세팅하셔야 할 것 같은데요. 보통 컨피그로 빼고 적절히 조절해주는 게 맞을 것 같구요. 제가 질문을 잘 이해했나 모르겠네요.


이렇게 하는 것이 맞다면 제가 생각을 잘못한 것이네요. :oops:
그렇다면 ack에 대한 timeout 에 대한 처리는 어떻게 하는 것인가요?
select에서의 timeout 값은 1초로 이미 사용중이거든요.
제가 생각하기에는

send() -> alarm(timeout), 전역변수 type=data_type ->
1 : select () -> FD_ISSET() -> rec_type == type : alarm(0) -> keep going....
2 : SIG_ALRM 발생 -> signal_handler -> switch(type) 다시 전송 ~

간단하지만 위와 같이 하면 될까요? 조금만 더 가르침을 주십시요.

익명 사용자의 이미지

글쓴이: 익명 사용자 / 작성시간: 화, 2005/12/20 - 6:39오후

heoks wrote:
답변에 먼저 감사드립니다. :D
spacelee wrote:
잘 아시겠지만, tcp를 쓰는 상황에서 커넥션을 맺은 단계에서 100% 처리하려고 하는건 네트웍 구조상 불가능하구요. 일정 시간 후 커넥션을 다시 맺어 트랜잭션을 다시 시작하는 식으로 커넥션 윗 레벌에서 에러 처리 flow에 대해서 대비를 하고 있어야 하겠죠.

그런 상황이라면, timeout값은 그 상황에서 선택적으로, 경험적으로 세팅하셔야 할 것 같은데요. 보통 컨피그로 빼고 적절히 조절해주는 게 맞을 것 같구요. 제가 질문을 잘 이해했나 모르겠네요.


이렇게 하는 것이 맞다면 제가 생각을 잘못한 것이네요. :oops:
그렇다면 ack에 대한 timeout 에 대한 처리는 어떻게 하는 것인가요?
select에서의 timeout 값은 1초로 이미 사용중이거든요.
제가 생각하기에는

send() -> alarm(timeout), 전역변수 type=data_type ->
1 : select () -> FD_ISSET() -> rec_type == type : alarm(0) -> keep going....
2 : SIG_ALRM 발생 -> signal_handler -> switch(type) 다시 전송 ~

간단하지만 위와 같이 하면 될까요? 조금만 더 가르침을 주십시요.

허~ 위에서 이상한 조언들이 많아서 헷갈리셨군요.
거듭 말씀드리지만, 재전송하는 로직을 작성하지 마세요.

엄밀히 말하면, 일단 send()해서 에러가 없다면, 원격지로 언젠가는 갑니다. 만일 안간다면, 연결이 단절된 경우밖에 없습니다.
즉, 재전송한다면, 연결이 끊겨서 연결부터 다시하고 전송하는 것인데, 이를(재연결후 전송) 재전송이라고 한다면 재전송이 되겠지요.
* 언젠가는 간다? : 응용프로그래머가 우아하게(단순 send()) 코딩하는 동안, 운영체제는 백조의 다리처럼 열심히 헤엄치는데,....
운영체제는 상대가 받을때까지 보냅니다(필요시 재전송). 순서맞춰서, 에러없이.... 반면, 받는 운영체제는 에러없이, 중복없이 ,순서맞춰서 받습니다. 중복되면 버리고....일단 운영체제가 제대로 받으면, recv()호출한 프로세스에게 데이터를 줍니다.

다음 1개의 클라이언트/서버 쌍에 대해 가정해 봅시다.
=> 클라이언트측
1. 인증정보 #1전송
2. 응답이 없음(응용프로그램수준)
3. 특정시간동안 응답이 없음(타임아웃)
4. 재전송(인증정보 #2)

=> 서버측에서의 인지
1. 누군가 접속함
2. 정보가 안옴 (클라이언트는 2-3단계: 이때 순간적으로 네트워크상태가 불량했음;물리적이건 논리적이건간에;소위 ping해보니 RTT가 수초걸림)
3. 인증정보 #1도착
4. 인증정보 #1의 응답 송신
5. 인증정보 #2도착
6. 서버 : ??????????

단순히, 전송후 응답을 받게 프로그램을 작성한다는 마음으로 작성하세요.
send("인증정보"); // client->server
recv("인증응답"); // server->client

이를 select()를 써서 짜건, nonblocking으로 짜건, blocking으로 짜건 TCP라면 재전송을 하지 않습니다. 단지 연결이 단절되었나? 를 판단하고 그에 대한 처리를 할 뿐입니다.

* 위처럼 만드는 경우는 보통 패스워드를 특정 시간안에 입력하지 않으면 실패로 간주하는 경우외에는 거의 없습니다.

spacelee의 이미지

글쓴이: spacelee / 작성시간: 화, 2005/12/20 - 7:11오후

heoks wrote:
답변에 먼저 감사드립니다. :D
spacelee wrote:
잘 아시겠지만, tcp를 쓰는 상황에서 커넥션을 맺은 단계에서 100% 처리하려고 하는건 네트웍 구조상 불가능하구요. 일정 시간 후 커넥션을 다시 맺어 트랜잭션을 다시 시작하는 식으로 커넥션 윗 레벌에서 에러 처리 flow에 대해서 대비를 하고 있어야 하겠죠.

그런 상황이라면, timeout값은 그 상황에서 선택적으로, 경험적으로 세팅하셔야 할 것 같은데요. 보통 컨피그로 빼고 적절히 조절해주는 게 맞을 것 같구요. 제가 질문을 잘 이해했나 모르겠네요.


이렇게 하는 것이 맞다면 제가 생각을 잘못한 것이네요. :oops:
그렇다면 ack에 대한 timeout 에 대한 처리는 어떻게 하는 것인가요?
select에서의 timeout 값은 1초로 이미 사용중이거든요.
제가 생각하기에는

send() -> alarm(timeout), 전역변수 type=data_type ->
1 : select () -> FD_ISSET() -> rec_type == type : alarm(0) -> keep going....
2 : SIG_ALRM 발생 -> signal_handler -> switch(type) 다시 전송 ~

간단하지만 위와 같이 하면 될까요? 조금만 더 가르침을 주십시요.

위 수도코드만 봐서는 정확히 이해하기 어려운 부분이 있네요.
select에서 타임아웃 메커니즘이 있으니깐, alarm을 안쓰셔도 되지 않나여? select에서 timeout값으로 세팅을 하면 될텐데여
스티븐스 책 관련된 장을 자세히 보시는게 더 도움이 되지 않을까 싶습니다.

그리고, 제가 드린 얘기가 잘못 이해가 된거 같아서..^^;;
제가 "커넥션 윗 레벌에서 에러 처리 flow에 대해서 대비를 하고 있어야 하겠죠."라고 한 부분은 네트웍이나 호스트, 프로세스가 죽어서, tcp 커넥션이 끊어지는 경우에 대해서 처리 flow가 있어야 한다는 뜻입니다.
어떠한 네트웍 서버,클라이언트이건 간에 그 부분에 대해서는
처리 플로우가 있어야 되거든요.

그 부분을 무시하신다면 생각하신게 맞습니다.
즉, 커넥션이 맺어진 상태(소켓을 계속 사용하고 있는 상태) 에서는
데이터를 재전송할 필요가 없는게 맞습니다.
위에서 "다시 전송~" 이라는 부분은 필요없다는 얘깁니다.

단지, 타임아웃값을 애플리케이션,네트웍 상황을 고려하여서
정하면 되구요. 상대방 애플리케이션이 대부분의 job을 10초안에 충분히 처리하고 네트웍이 LAN 정도의 상황이라면 timeout은 20~30초 정도만 해도 충분하겠죠.

아무래도 제가 쉬운 얘기를 복잡하게 한거 같네요..^^;;

스티븐스 책에서 alarm쪽 이용하는 부분 말고 select 에서 타임아웃 이용하는 부분 참고해보세요. 둘다 쓰실 필요는 없습니다.

권위를 의심할 것,어긋남을 존경할 것,자리잡기를 거부할 것,항상 자신을 재창조할 것 - MIT 미디어랩 -

heoks의 이미지

글쓴이: heoks / 작성시간: 수, 2005/12/21 - 7:46오전

Anonymous wrote:

허~ 위에서 이상한 조언들이 많아서 헷갈리셨군요.
거듭 말씀드리지만, 재전송하는 로직을 작성하지 마세요.

엄밀히 말하면, 일단 send()해서 에러가 없다면, 원격지로 언젠가는 갑니다. 만일 안간다면, 연결이 단절된 경우밖에 없습니다.
즉, 재전송한다면, 연결이 끊겨서 연결부터 다시하고 전송하는 것인데, 이를(재연결후 전송) 재전송이라고 한다면 재전송이 되겠지요.

제가 알고 있는 것과 같습니다. 실제로 문제가 생겼던 적도 없었구요. 다만 저보다 경험이 더 많은 직장선배가 당연히 일정시간 동안 ack가 없으면 재전송해야 한다고 해서... :oops: 제가 알고 있는 것이 전부는 아니다는 생각에서 KLDP에 물어본 겁니다.
답변 감사드립니다.

heoks의 이미지

글쓴이: heoks / 작성시간: 수, 2005/12/21 - 7:50오전

spacelee wrote:
heoks wrote:
답변에 먼저 감사드립니다. :D
spacelee wrote:
잘 아시겠지만, tcp를 쓰는 상황에서 커넥션을 맺은 단계에서 100% 처리하려고 하는건 네트웍 구조상 불가능하구요. 일정 시간 후 커넥션을 다시 맺어 트랜잭션을 다시 시작하는 식으로 커넥션 윗 레벌에서 에러 처리 flow에 대해서 대비를 하고 있어야 하겠죠.

그런 상황이라면, timeout값은 그 상황에서 선택적으로, 경험적으로 세팅하셔야 할 것 같은데요. 보통 컨피그로 빼고 적절히 조절해주는 게 맞을 것 같구요. 제가 질문을 잘 이해했나 모르겠네요.


이렇게 하는 것이 맞다면 제가 생각을 잘못한 것이네요. :oops:
그렇다면 ack에 대한 timeout 에 대한 처리는 어떻게 하는 것인가요?
select에서의 timeout 값은 1초로 이미 사용중이거든요.
제가 생각하기에는

send() -> alarm(timeout), 전역변수 type=data_type ->
1 : select () -> FD_ISSET() -> rec_type == type : alarm(0) -> keep going....
2 : SIG_ALRM 발생 -> signal_handler -> switch(type) 다시 전송 ~

간단하지만 위와 같이 하면 될까요? 조금만 더 가르침을 주십시요.

위 수도코드만 봐서는 정확히 이해하기 어려운 부분이 있네요.
select에서 타임아웃 메커니즘이 있으니깐, alarm을 안쓰셔도 되지 않나여? select에서 timeout값으로 세팅을 하면 될텐데여
스티븐스 책 관련된 장을 자세히 보시는게 더 도움이 되지 않을까 싶습니다.

그리고, 제가 드린 얘기가 잘못 이해가 된거 같아서..^^;;
제가 "커넥션 윗 레벌에서 에러 처리 flow에 대해서 대비를 하고 있어야 하겠죠."라고 한 부분은 네트웍이나 호스트, 프로세스가 죽어서, tcp 커넥션이 끊어지는 경우에 대해서 처리 flow가 있어야 한다는 뜻입니다.
어떠한 네트웍 서버,클라이언트이건 간에 그 부분에 대해서는
처리 플로우가 있어야 되거든요.

그 부분을 무시하신다면 생각하신게 맞습니다.
즉, 커넥션이 맺어진 상태(소켓을 계속 사용하고 있는 상태) 에서는
데이터를 재전송할 필요가 없는게 맞습니다.
위에서 "다시 전송~" 이라는 부분은 필요없다는 얘깁니다.

단지, 타임아웃값을 애플리케이션,네트웍 상황을 고려하여서
정하면 되구요. 상대방 애플리케이션이 대부분의 job을 10초안에 충분히 처리하고 네트웍이 LAN 정도의 상황이라면 timeout은 20~30초 정도만 해도 충분하겠죠.

아무래도 제가 쉬운 얘기를 복잡하게 한거 같네요..^^;;

스티븐스 책에서 alarm쪽 이용하는 부분 말고 select 에서 타임아웃 이용하는 부분 참고해보세요. 둘다 쓰실 필요는 없습니다.

위에서 select는 이미 사용하고 있다고... ㅎㅎ
Client 쪽에서도 하는 일이 있기 때문에 타임아웃으로 그렇게 큰 시간을 잡을 수 없습니다. 정성스런 답변 감사합니다. :D

댓글 달기

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

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
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.