[ CnUnix ] in KIDS 글 쓴 이(By): unixboy (대철이삼촌) 날 짜 (Date): 2001년 10월 18일 목요일 오후 08시 48분 23초 제 목(Title): 또 질문이 있는데요. 장난삼아 질문합니다만, 임의의 두개의 머신이 선(이게 무슨 선인진 잘 모르고요)으로 연결되어 있고, 한 쪽 선을 뺏다 꼽았다 하는 짬뽕같은 장애를 극복해내고 통신이 되는 프로토콜이 있나요? [ CnUnix ] in KIDS 글 쓴 이(By): hongcho (홍이) 날 짜 (Date): 2001년 10월 19일 금요일 오전 02시 33분 14초 제 목(Title): Re: 또 질문이 있는데요. 대부분 무선 프로토콜이 아무래도 이래야 되지 않을까요, 자세히는 모르지만... [ CnUnix ] in KIDS 글 쓴 이(By): unixboy (대철이삼촌) 날 짜 (Date): 2001년 10월 19일 금요일 오후 12시 40분 15초 제 목(Title): Re: 또 질문이 있는데요. 아예... v.52 나 E1/T1 쪽은 그렇게 되는 것으로 알고 있는데... 이건 그냥 링크 수준의 physical layer에서 동작하는 거고... 패킷 수준의 프로토콜에서는 의미가 없을까요? 그냥 packet drop 에 관련된 timer mechanism 이나.. 그런 것 외에는 방법이 없는 건지 어떤건지... 참.. ATM cell 에서의 가용대역폭 필드인가가 있었던것도 같습니다만... 제가 질문해놓고도 뭔지 잘 모르겠네요. 하하. [ CnUnix ] in KIDS 글 쓴 이(By): qkim ( NGI Lab. ) 날 짜 (Date): 2001년 10월 19일 금요일 오후 01시 13분 10초 제 목(Title): Re: 또 질문이 있는데요. 정확히 어떤 상황인지 이해가 안 갑니다만... 1. 라우터 전원 껐다가 다시 켜면.. 그래도 계속 기존 connection이 유지 되지요. 갑자기 packet loss가 많아져서 recovery하느라 바빠지겠지만.. 2. 결국 인터넷에서는 TCP든 UDP든 stateless인 IP datagram이 오가기 때문에.. 끊어졌다 붙었다 하는 상황에서도 계속이 통신이 될 수 있습니다. 다만 문제는... RTT 값 이하의 매우 짧은 시간이라면 아무런 문제가 없겠지만.. 그 이상이라면.. TCP 경우에 congestion avoidance가 동작하면서 exponential back-off 들어가면서 성능이 떨어질 것이고.. 수십초 간격이라면.. TIMEOUT에 걸려서 connection이 끊어지면서 통신이 안 될 것이고.. 정확히 몇 초인지는 스티븐스 책에 나올듯 하고.. 보다 정확히는 코드를 들어다 봐야 알 수 있겠지요.. 3. CDMA 기반 망에서는 불안정한 네트워크의 다량 packet loss에 대비하여 RLP를 끼워 두었습니다. 100% 복구하지는 않고.. 유선망에 비교할 수 있는 정도로 만들어 줍니다. 그래서 KTF인가.. Mobile Explorer쓰는 곳에서 그냥 유선망에서 쓰던 TCP/IP 그대로 씁니다. 일본 I-mode도 그렇고.. 하지만 TCP 경우에 그래도 손볼 곳이 있다고 하는 사람들이 있습니다. WAP Forum에서도 wireless-profiled TCP를 만들었기도 하고요... [ CnUnix ] in KIDS 글 쓴 이(By): terzeron (the cowboy) 날 짜 (Date): 2001년 10월 19일 금요일 오후 09시 39분 32초 제 목(Title): Re: 또 질문이 있는데요. 일반적으로 웬만한 프로토콜이 원칙적으로는 failover한 면이 있는데 정도의 문제 아닐까요? 예를 들면, 케이블을 뽑아 놓은 시간이 짧아지면 프로토콜이 알아채지 못하고 지나가는 수도 있는 거니까요. packet을 다루는 레벨에서의 프로토콜을 말씀하시는 거라면 network layer나 transport layer(또는 application layer)를 말씀하시는 것 같은데... 일단 application level에서는 그렇게 app를 만들면 될 거구요. network layer는 ip routing이 주가 되니 고칠 게 별로 없고... transport layer에서라면 unreliable한 link를 감안해서 timeout을 적절히 사용한다든가(그냥 timeout 값을 높이면 성능이 나빠질 테니) fast retransmission 메커니즘을 뜯어고친다든가 중간 노드에서 segment를 캐싱하는 방법 정도가 있지 않을까요. 무선 링크를 생각하신다면 transport layer에서 burst/transient error인지 congestion인지 링크의 상태를 알기는 어렵습니다. 여러가지 꽁수를 써야 하는데 그러느니 wireless link layer에서 해결하는 게 여러 모로 효율적인 것으로 알려져 있습니다. 일반적으로 인터넷은 fault-tolerant와는 거리가 멀기 때문에 이런 프로젝트도 있다고 합니다. http://www.darpa.mil/ito/psum2000/J912-0.html 저도 원하시는 답과는 거리가 멀군요. -_-;;