: 안녕하세요 임프님을 비롯한 여러분, 몇년만에 보는 눈오는 이브이군요.
: 모두들 건강하시기 바랍니다.
: 참, 임프님, 홈페이지가 옮겨졌군요. 저는 계속 두루넷에서
: 임프님을 찾느라고 애를 태웠는데 이리로 오셨다니, 어쨌든 다시 만나뵙게
: 돼서 반갑습니다. (휴-)
: 먼저 올린 디비관련 질문에 대한 답변 감사드립니다. 좋은 계기가 됐어요.
: 지금 당장은 현실적으로 어렵지만 꼭 한 번 도전해볼 생각입니다.
: 폴더 삭제건도 실례를 무릅쓰고 조만간 다시 질문 올리겠습니다.
:
: 오늘 문의 드리고 싶은 것은 제가 납품하고 있는 고객의 네트워크가
: 상당히 불안정해서 가끔 잘 연결해서 쓰고 있는 오라클로부터
: ORA-003114 Not Connected To Oracle등의 메시지가 뜨는 경우가
: 있습니다. 빈도 자체가 많지 않고(월 1회나 그 미만) 제 잘못이
: 아닐 가능성이 크다는 이유로 당장 압박을 받는 것은 아니지만
: 마음에 계속 걸려서요. 물론 try catch블록으로 에러를 검출해서
: 그 메시지 번호를 조사해 처리를 하면 아쉬운 대로 다운되는 것은
: 막을 수 있겠으나 근본적인 대책이라고 할 수는 없겠지요.
:
: 그래서 네트워크 관련API함수나 빌더측에서 제공하는(TSession이 해당될까나?)
: 방법으로 네트워크의 장애를 딱집어 낼 수 있는 방법이 필요합니다.
: 네트워크는 아직 초심자라 (다른 것도 마찬가지지만) 전혀
: 방향을 못잡고 헤매고 있습니다. 조언을 부탁드리겠습니다.
:
: 그럼 오늘 모두 좋은 분들과 좋은 시간들 보내세요.
:
: The solution would be somewhere over the rainbow.



임펠리테리입니다.

확실한 해결책은 없는 걸로 알고 있습니다. 네트워킹에서, 갑자기 라인의 상태가 좋지 않아져서
(예를 들어서 라인전송 속도에 비해 트래픽이 급격히 늘어났을때나, 최악의 경우 랜 선이 갑자기
빠졌을 때 등) 접속이 사실상 끊어지는 경우를 알아낼 방법은 네트웍 프로그래머들 사이에서
오랜 이슈였습니다만, 아직도 뚜렷한 해결책은 없습니다. 랜선을 뽑아버려도 아직 접속중인 것으로
나오는데에야 더이상 할 말이 없죠.

그래서 대부분의 네트웍 프로그래머들이, 일정 주기마다 접속을 시도해보고 커넥션 타임아웃이
발생할때 연결이 불안정한 것으로 간주하는 방법을 사용합니다. 오라클 서버측에 단순히 연결을
시도했을 때 응답만하는 소켓 프로그램을 하나 띄워놓고, 디비클라이언트 컴퓨터 측에서 접속을
시도하는 측에서 정기적으로 접속을 시도해보는 거죠. 물론 절대 완벽한 해결책이 못됩니다.

그 외에도 네트웍 프로그래머들의 경우 자기만의 테크닉으로 이런 문제점을 넘기는 경우를 종종
보았는데.. 혹 이 글을 보시는 분들 중에서도 다른 방법을 사용하시는 분은 조언을 해주시면
감사하겠습니다.

그럼 이만...