재미있는 웹서비스를 하나 알게 되었다.


특정 사이트를 입력하면, 그 서버의 시간을 알려주는 서비스이다.


잘 몰랐는데, 특정 시간부터 접수가 되는 수강 신청같을 것을 할 경우에 많이들 사용한다고 한다.


내가 알게된 사이트의 주소는 http://time.navyism.com/ 인데, 유사한 서비스가 더 있는 것 같다.


암튼.....


대개 서버는 타임서버와 정기적으로 동기화를 한다. 시간 정보는 디지털 세계에서는 아주 중요하고 민감한 정보이기 때문이다.


하지만, 역시나.......   타임서버와 정기적으로 동기화를 한다고 해도, 모든 서버들이 항상 같은 시간을 유지하지는 못한다.


타임서버와 동기화한 여러대의 PC를 시간을 두고 비교해 보면 이 점을 알수 있다.


심지어는 아주 세밀하게는 휴대폰 시간마저도 완벽히 똑같지는 않다.

(정말이다....!! 처음 이 사실을 알았을땐, 충격적이었다. 지금 생각해 보면 당연하거지만)


그래서 위와 같은 서비스가 나오나 보다.




그렇다면, 웹서버의 시간을 어떻게 알아내는 것일까??


답은 HTTP 헤더에 있다.


서버는 HTTP 응답 헤더에 자신의 시간 정보를 내린다.


따라서 이 정보만 잘 해석하면 그 서버의 시간 정보를 알 수 있고, 수강 신청을 재빠르게 할 수도 있다. ㅋ


하지만, HTTP 응답 헤더에 나오는 서버의 시간 정보는 초 단위이다!!.


이 말은, HTTP 헤더를 받는 통신 시간을 계산해서 시간을 보정한다 해도, 실제 서버 시간과는 최대 999ms의 오차가 날 수 있다는 것이다.


웹서버가 12시 59분 59초 999ms 에 HTTP 헤더를 12시 59분 59초로 내려줬고, HTTP 헤더를 받는데 10ms가 걸렸다고 생각해보자.


우리는 12시 59분 59초라는 정보를 웹서버 시간으로는 13시 00분 00초 009ms일때에 받게 되는 것이다.


이 부분은 현재 정보가지고는 어떻게 할 수가 없다. (요청하는 시간을 지능적으로 여러번 한다면 오차값이 적게 나오도록 수렴해갈 수 있을것 같긴 하다)

----------------------------------------------------------------------------------------------------------------

추가 : http 헤더 요청을 연속으로 보내서 초가 바뀔때의 타이밍을 잡는 방법으로 최대 20ms 정도의 오차 범위내에서 정확한 시간을 알아 낼 수 있었다.

----------------------------------------------------------------------------------------------------------------



일단 현재까지의 생각을 가지고 C#으로 서버의 시간 정보를 가져오는 코드를 아래와 같이 만들어봤다. (사실은 다른 용도로 사용하기 위한 것이지만.....)



한가지, 연속으로 같은 요청을 하다 보면, 응답 대기 시간이 길어지는 경우가 생기기 때문에, 싱글 쓰레드에서는 프로그램이 멎는 현상이 생긴다.

따라서, 멀티 쓰레드로 구현하여 프로그램이 자연스럽게 동작하도록 하는 것이 필요하다.

'C#.NET' 카테고리의 다른 글

마우스 시스템 이벤트 흉내내기  (0) 2013.02.01
블로그 이미지

설기아빠

,

아이폰은 다운로드 헤더를 대충 만들어도, 알아서 잘 보여준다.

그런데, 안드로이드 단말기는 그렇지 못한다.

지금까지 확인해 본 바로는 Content-Type의 mime type 과 Content-Disposition의 filename을 정확히 만들어 주는것이 아주 중요하다.


여기 저기 검색을 해 보면, 3가지 규칙을 얘기한다.

1. Content-Type을 application/octet-stream으로 할것

2. Content-Disposition을 파일명을 Double Quotation mark로 감쌀것.

3. 파일명의 확장자는 대문자로 할것.


하지만 이 규칙마저도 안드로이드 프로요 버전 이하일 경우에 해당하는 것 같다.

지금은 위 규칙에서 2번, 3번을 꼭 지키지 않아도 충분한것 같다.

참고로 아래는 일반적인 다운로드 코드이다.(IE를 잘 지원하기 위해서는 별도의 코드가 더 필요하다. ㅡㅡ)


하지만, 이번의 경우에는 파일 다운로드를 브릿지 역할을 하는 중간 서버를 통해서 해야 했기 때문에, 이렇게 간단하지가 않았다.

원본 서버에서 다운로드할 파일명과 mime-type을 HTTP Header에 내려줬기 때문에, 브릿지 역할의 서버에서는 이러한 정보를 간단한 방법으로는 안드로이드 단말기로 내려줄 수가 없었다.

아무 정보 없이, 확장자도 없이 다운로드 되는 케이스가 있었으며, 이 경우에 아이폰은 알아서 잘 보여줬지만, 안드로이는 정상적으로 보여주지 못하거나, 다운로드 실패가 되었다. 아..........


결국, 브릿지 서버에서 해당 화일을 HTTP Header 를 확인하여서 Header 정보를 바탕으로 파일을 저장하고, 이를 다시 내려주기로 했다.


Header 정보를 얻기 위해서는 curl의 옵션을 아래와 같이 사용했다.

다운로드 브릿지 서버를 사용해야 하는 이상한 상황이어서 더더욱 해매고 말았다.

새삼스럽게 'iOS가, Safari가 정말 잘 만들었진거구나' 라는 생각을 하게 되었다.

'PHP' 카테고리의 다른 글

Apache 서비스 포트 추가하기  (0) 2012.11.15
블로그 이미지

설기아빠

,

Javascript Closure를 이해한다고 생각했는데, 정확히 이해하고 잘 사용하는것이 아직은 안되는 것 같다.


이미지를 하나씩 로딩하는 객체를 만드는 과정에서 클로저를 사용해야만 했다.

처음에는 아래처럼 단순히 function 참조를 바로 연결해주었는데, 크롬에서는 정상 작동하는데, IE에서는 오류가 났다.

IE에서 실제로는 이미지 로드가 완료되지 않았는데, 함수가 호출되면서 이미지 로드가 끊기는 오류가 발생했다. 에휴..IE.....

그래서 단순하게 그럼 약간 지연시켰다가 호출해 보자라는 생각에, setTimeout에 클로저를 사용해서 호출해봤다.


IE 7,8 에서 오류......

오류 메시지는 아직 지원하지 않는 스크립트 기능이라나?... 참..나..


결국 아래와 같이 클로저를 수정해서 문제는 해결되었다.


this객체와 i 변수를 익명 함수에 던짐으로 변수를 참조하도록, 연결이 유지된 함수를 반환, 실행하도록 하였다.

클로저에 대해서 조금 더 이해할 수 있게 되는 계기였다.

블로그 이미지

설기아빠

,
최근에 Adobe Labs에서 Adobe Shadow라는 것을 내놓았다.

간단히 설명하자면, PC에서 보는 웹페이지 화면을 모바일 단말기와 싱크해서 모바일에서는 어떻게 보여지는 확인 할 수 있게 해 준다.
이 뿐만 아니라, Inspector와 같은 크롬용 개발자 도구를 모바일에 연결해서 볼 수 있게 해준다!!!!!
정말 이런 기능이 필요했다.

올바른 작동을 위해서 맥또는 윈도우에서 구동될 호스트 프로그램, 확장 기능이 설치된 크롬 브라우저, 동일 네트워크에서 구동이라는 조건이 필요하다. (윈도우일경우에는 봉주르 서비스 설치가 추가로 필요하다)

백문이 불여일견 아래의 소개 동영상을 보자. 

 

동영상에서 보여주는것처럼, 아이폰, 아이패드, 안드로이드 등의 모바일 단말기를 한번에 연결해서 볼 수 있다.
맥에서 설치해서 해보니, 간혹 Inspector가 연결을 잘 못하는 경우가 있었지만 대체적으로 쓸만했다.

 
자세한 소개 및 설치 방법은 아래의 공식 사이트에서 확인하면 된다.

http://labs.adobe.com/technologies/shadow/ 

이제 뉴 아이패드 한국 발매 시점에 맞추어, 아이패드의 필요성을 회사에 강조하기만 하면 되겠다!!


블로그 이미지

설기아빠

,
모바일용으로 디자인된 페이지를 작업하면서, 그 동안 해결하지 못하고 계속 궁금해 했던 문제를 드디어 해결했다.

다름이 아니라, 상단 메뉴바를 만들때, UL과 LI로 메뉴를 구성하다 보면 넓이를 도합 100%가 되도록 정확히 구성했음에도 불구하고, 100%를 차지하지 못하는 경우가 생긴다.

예를 들어, 메뉴가 3개라고 하면, 34%, 33%, 33%로 구성하거나, 33.33%로 새개 모두를 구성하게 된다.
그런데 이렇게 하면 아래 그림과 같이 오른쪽 끝에 빈 공백이 생긴다.


오른쪽 끝에 검정색 공백이 생겼다.



디자이너가 이와 같은 문제를 가지고 여러번 문의해 왔지만, 정확한 해결책을 찾지 못해 고심했다
그러다가 오늘, 본격적으로 이 문제를 짚고 나가야겠다는 생각을 했다.

문제는 webkit 계열 브라우저에서 width 속성을 퍼센트로 주었을때 발생하는것이었다.

아이폰 기준으로 320px의 넓이를 3등분하면, 106.666666.....px이 나온다. 아마도 webkit 계열 브라우저는 소수점 이하 값을 무시하고 넓이를 계산해서 렌더링하는것으로 보인다.
때문에, 소수점이 없이 정확히 떨어지는 퍼센트 값에 대해서는 정확하게 보여줄 수 있었던 반면, 소수점이 나오는 값에 대해서는 실제보다 작게 계산되어 여백이 생기는것 같다.

그렇다면, 이에 대한 해결책은 무엇일까?




약간의 꼼수 같지만, 위와 같은 스타일로 보기 싫은 공백 없이 메뉴바를 보여줄 수 있게 되었다.
최종 결과 화면은 아래와 같다.



깔끔하게 문제를 정리하게 되었다.


 
블로그 이미지

설기아빠

,
오늘 회사에서 오전부터 디자이너와 마케터가 계속 자리를 오가며 뭔가를 열심히 수정하고 있었다.

마케터가 바로 나의 건너편 자리인 관계로 가끔식 들려오는 얘기를 들을 수 있었다.

별로 귀담아 듣지 않았었는데, 퇴근 시간이 가까워질때까지 문제가 해결되지 않자 디자이너가 나에게 와서 문의를 했다.

문제인즉슨, html형식으로 보내는 마케팅 메일의 디자인이 이번에 개편이 되어서 테스트를 하고 있는데, 다른 웹메일등에서는 잘 보여지는데, 유독 Outlook에서는 메일 하단에 하얀 가로줄이 생긴다는 것이었다.

디자이너는 이 문제가 메일 내용의 길이를 줄이면 가로줄이 안생기는 것으로 보아,  길이가 길어서 그런것 같다고 하였다.

좀 납득이 되지 않았지만, 현상을 보니 정말이었다.

그래서 Outlook의 html 렌더링 엔진에 대해서 찾아보기 시작하였다.

결국 알아낸 결론은,


1. Outlook 2007 이상은 MS-Word의 엔진을 사용하고 Outlook 2003은 IE의 엔진을 사용한다.

2. Outlook 에서의 html 렌더링은 상당히 많은 제약이 따른다.
    (MSDN에서 자세히 설명해 준다 http://goo.gl/4L6c, http://goo.gl/BF9sS)
 

3. 그리고... html 메일에서 레이아웃을 잡기 위해 필수로 사용하게 되는 Table 의 길이가 23.7inch (약 1,790pixel)보다 크면 자동으로 구분줄을 삽입한다!! (이것이 바로 예의 하얀 가로줄이다)


하얀 가로줄이 생기는 것에 대한 해결책은 몇가지가 있는것 같은데, 가장 확실한 것은 가로줄이 생길만큼의 긴 Table을 만들지 않는 것이다.

다행히도 디자이너가 코딩한 결과물은 하나의 큰 테이블이 컨텐츠를 담은 여러개의 테이블을 감싸고 있는 형태였다.

그래서 바깥쪽의 긴 테이블을 빼고 컨텐츠 테이블만으로 구성을 하자 Outlook에서의 하얀 가로줄이 나오는 현상이 사라졌다.



 
블로그 이미지

설기아빠

,