2012-04-06 4 views
0

RFC 868 준수 시간 서버와 시간을 동기화하기위한 개념 증명을 보여주는 샘플 응용 프로그램을 빌드하려고합니다.구문 분석 바이너리 응답

지금까지 Java 소켓 API를 사용하여 서버에 연결하고 쿼리 할 수 ​​있었으며 서버에서 응답을받을 수 있지만 사람이 읽을 수있는 형식이 아닙니다.

응답은 다음과 같습니다. �)6 응답이 이진 형식으로 표시됩니다 (확실하지 않음). RFC 868Send the time as a 32 bit binary number라고 말합니다.

내 질문은 : 1) 어떻게이 응답을 구문 분석합니까? 2)이 접근 방식 외에도,이를 달성하기 위해 취해야 할 다른 권장 접근 방식이 있는지 알고 싶습니다.

미리 감사드립니다.

+0

왜 RFC 868인가 요즘 거의 모든 것이 NTP를 사용하고 있습니다 – Zoredache

+0

@Zoredache : 네, 저도 동의합니다 ...이 프로토콜에 대해 배우고 싶습니다 ... –

+0

32 비트가 4 바이트 (32/8).int 변수를 0으로 정의한 다음 루프마다 8 비트 씩 이동하고 스트림에서 다음 후속 바이트와 함께 비트 OR을 적용합니다. – ahanin

답변

2

1) 어떻게이 응답을 구문 분석합니까?

체크 아웃 아파치 코 몬즈 닷넷 라이브러리에서 source code of TimeTCPClient : 다른 권장 방법이있는 경우

public long getTime() throws IOException { 
    DataInputStream input; 
    input = new DataInputStream(_input_); 
    return (input.readInt() & 0xffffffffL); 
} 

public Date getDate() throws IOException { 
    return new Date((getTime() - SECONDS_1900_TO_1970)*1000L); 
} 

2) 외에 내이 방법에서, 나는 알고 싶어하는 내가해야 이것을 달성하기 위해서.

Apache Commons Net Library를 사용하여 API of TimeTCPClient을 확인하십시오.

Apache Commons Net home page이 도움이 되길 바랍니다.

+0

정말 고맙습니다! 스레드 내에서 1 초 시간을 업데이트하면 실제로 정확한 시간으로 시작하지만 결국 몇 밀리 초 뒤에 뒤떨어지기 시작합니다. 몇 밀리 초가 지나면 몇 초가 지나고 다시 커집니다. 이것은 RFC 868 호환 시간 서버와 공통된 것이 있습니까? 고마워 –

2

RFC에 명시된 바와 같이 이것은 1900-01-01T00 : 00 : 00 이후의 초입니다. 자바를 Long으로 변환하려면 기본 날짜를 1970-01-01T00 : 00 : 00으로 변경하고 1000을 곱하여 날짜를 얻습니다. 그런 다음이 값을 사용하여 새 날짜를 만들 수 있습니다.

소켓 입력 스트림을 DataInputStream에 랩핑하고 rfsOffset (정수를 사용)을 읽습니다.

int rfcOffset = -752253627; // Fri Apr 06 11:00:32 EDT 2012 
// Current offsets will be negative convert to long positive value 
long offsetSecs = rfcOffset + 4294967296L; 
System.out.println(offsetSecs); 
// Adjust time base from 1900 to 1970 and convert to millis 
long offsetMillis = (offsetSecs - 2208988800L)* 1000L; 
System.out.println(offsetMillis); 
Date rfcDate = new Date(offsetMillis); 
System.out.println(rfcDate.toString()); 

주 : 그럼 당신은 뭔가를 할 수있는 2036 시간까지이 유일한 작품은 밀리 세컨드의 일부 번호로 꺼집니다.

EDIT : RFC 868은 이전 프로토콜이므로 더 이상 동기화를위한 좋은 시간 원본으로 간주되지 않습니다. 좋은 시간 소스는 우리에게 NTP를 보내고 올바른 초를 반환합니다. 그것은 수 밀리 세컨드에서 벗어나지 만, 일반적으로 10 밀리 세컨드로 정확합니다. 많은 하드웨어 클럭이 상당히 많이 드리프트되며 NTP를 실행하는 경우에도 부정확 한 클록이있는 시스템에서 상당한 드리프트가 발생했습니다. NTP는 드리프트 클럭을 수정하지만 필요한 시프트를 결정하는 데 몇 분이 걸립니다. RFC 868은 오래되었으므로 배경 프로세스없이 휴대 전화의 시간을 가장 가까운 초로 설정할 수 있습니다. 휴대 전화가 제공 한 신호와 동기화 할 수 있으면 필요하지 않습니다.

+0

아 .. 그냥 확인하고 싶었 - 내가 스레드에서 1 초 시간을 업데이 트하면 .. 실제로는 정확한 시간으로 시작하지만, 결국 결국 몇 밀리 초 뒤에 지연 시작, 이후 몇 초되고, 자랍니다. 이것은 RFC 868 호환 시간 서버와 공통된 것이 있습니까? 감사. –

+0

위에서 언급했듯이, 이것은 소스의 클록 드리프트 문제와 같습니다. – BillThor

+0

안녕하세요, 당신을 이해한다면 너무 확신 할 수 없지만'소스 '라고 말할 때'타임 서버'를 의미합니까? 그렇다면 시간 서버에 한 번만 쿼리 한 다음 초기 타임 스탬프를 사용하여 스레드 내의 각 초로 시간을 업데이트한다고 말하고 싶습니다. –