Better Then YesterDay

 
Whitelisting
어떤 어플리케이션은 기본 제한이 충분하지 못하다고 생각할겁니다. 이러한 환경에서, 우리는 Whitelisting을 제공합니다. 특정 계정과 IP 주소를 화이트 리스트 하는 것이 가능합니다. 화이트 리스트된 계정이나 IP주소들은 시간당 20000개의 요청이 허용됩니다. 만약 당신이 화이트 리스팅을 고려해야하는 어플을 짜고 있다면 화이트 리스팅 요청서(whitelisting request form)를 작성해주십시오. 우리가 직접 리뷰하는 프로세스는 일주일정도 걸립니다. 만약 당신이 Whitelisting에 추가하거나 삭제해야할 IP주소가 있다면 변경에 대한 설명과 함께 요청서를 재작성해야 합니다. Whitelisting 요청에 대한 승인이나 거절은 요청서에 있는 이메일 주소로 전송됩니다.

IP whitelisting은 계정 rate limit보다 우위에 있습니다. 화이트 리스팅된 IP 주소로부터의 GET 요청은 사용자 제한이 아닌 IP 제한에서 제외됩니다. 그러므로 IP 기반 화이트 리스팅은 많은 사용자의 데이터를 요청하는 어플리케이션을 위한 최고의 방법입니다.

화이트리스팅은 POST 요청과 관련된 일간 업데이트와 follower 제한을 없애지는 않습니다. : 이 제한은 계정 기반으로 관리됩니다.

만약 트위터로부터 당신의 계정이나 IP 주소가 화이트 리스팅 승인을 받는다면, 당신은 당신의 화이트 리스팅을 accounts/rate limit status 메소드로 이를 증명할 수 있습니다. 증명서와 함께 이 메소드를 호출하면 승인된 사용자의 rate limit 상태가 리턴되고, 증명서 없이 호출하면 호출한 IP 주소의  rate limit 상태가 리턴됩니다.

Search API Rate Limiting
Search API는 IP 주소에 의해 rate limit됩니다. 주어진 IP 주소로부터 요청될 수 있는 search 요청의 숫자는 search rate limiter에 의해 계산됩니다. 클라이언트가 주어진 시간동안 만들수 있는 요청의 정확한 갯수는 알려지지 않았습니다. Search API는 REST API처럼 시간당 150개의 요청으로 제한되지는 않습니다. 숫자는 좀 더 크며, 대부분의 어플리케이션에서 관대하고 충분하다고 생각하고 있습니다. 우리는 불필요한 search의 사용을 억제하기 위해 정확한 갯수를 알려주지 않을겁니다.

Search API를 사용할때는 어플리케이션이 특별하고 확인가능한 사용자 에이전트 스트링(User Agent String)을 가지고 있어야 합니다. HTTP Referrer가 있으면 좋지만 반드시 필요한 것은 아닙니다. Search API를 사용하지만 사용자 에이전트 스트링을 가지고 있지 않은 사용자들은 좀더 낮은 rate limit를 받게 됩니다.

Search API의 rate limit를 초과하는 어플리케이션은 요청에 대해 HTTP 503 응답코드를 받을겁니다. 이 에러 상태를 보고 이것이 언제 사용가능해지는지를 알려주는 Retry-After 헤더를 참조하는 것이 최고의 방법입니다. Retry-After 헤더값은 다른 요청을 제출하기 전에 기다려야 하는 시간을 초단위로 알려줍니다.(예를들면 Retry-After: 67)

Whitelisting
REST API와 달리 Search API에서는 white list와 관련된 방법이 없습니다. 그러나 특별한 상황에서는 Search 요청의 rate limit을 올리기 위해 노력하고 있습니다. 우리는 Search API를 위한 우선권이 있는 화이트 리스트를 가지고 있지 않습니다. 당신은 우리가 화이트 리스팅에 대해 논의하기 전에 좀 더 많은 캐패시티가 필요다고 증명할 수 있는, 잘 동작하는 어플리케이션을 가지고 있어야 합니다. 만약 당신이 당신의 어플리케이션이 요청을 적절하게 제한하고 통합하기 위해 할 수 있는 모든것을 하고 있다고 느낀다면, 당신이 필요한것을 논의하기 위해 트위터에 연락하십시오. Search API는 IP 주소에 대해서만 화이트리스팅 할 수 있고, 계정으로는 하지 못합니다. 이것은  구글 어플 엔진과 같은 클라우드 플랫폼, Search 화이트 리스팅을 받을 수 없는 스태틱 IP 주소가 없는 어플리케이션을 제외한 대부분의 상황에서 잘 동작합니다.

Rate Limiter를 피하는 방법
Rate Limiter로부터 생기는 문제를 피하기 위해 다음과 같은 일반적인 테크닉과 디자인이 사용될 수 있습니다.
    1. 캐싱(Caching) : 당신이 많은 양의 요청을 할거라고 생각한다면, API 응답을 당신의 어플이나 사이트에 저장하세요. 예를들어 매우 유명한 웹사이트에서 모든 페이지 로드마다 트위터 API를 호출하지 마십시요. 대신에 API를 좀 더 덜 빈번하게 호출하고, 응답을 클라이언트측에 저장하고, 페이지 로드시에는 저장된 것을 보여주세요.
    2. 접속된 사용자를 우선순위화 하십시오 : 당신의 사이트가 많은 트위터 사용자들을 관리하고 있다면(예를들어, 그들의 현재 상태나 그들의 트위터 사용의 통계를 가져온다면), 최근에 당신의 사이트에 로그인한 사용자들의 데이터만 요청하는 것을 고려하십시오.
    3. Search back-offs : 만약 당신의 어플리케이션이 매우 많은 양의 search 용어를 모니터링 한다면, 아무런 결과가 없는 서치결과에 대한 용어에 대해서는 덜 자주 요청을 보내십시오. back-off를 사용함으로써 거의 변하지 않는 요청 쿼리의 사이클을 낭비하지 않고 요청에 대한 최신 상황을 알 수 있습니다. 

Blacklisting
우리는 당신이 rate limit을 존중해줄것을 요청합니다. rate-limiter를 피하기 위한 일관된 failure는 트위터에게 자동으로 당신의 어플리케이션을 블랙리스팅하라고 신호를 보냅니다. 만약 클라이언트가 요청에 대한 응답을 받지 못한다면 당신이 블랙리스트되었음을 알아야합니다. 이것은 API 요청이 블랙홀 아래로 보내지는것과 같습니다.

만약 당신의 어플리케이션이 블랙리스트되었고 당신이 서비스를 다시 시작하고 싶다면 다음과 같이 하십시오
    1. 당신이 REST API를 사용한다면, 계정이나 컴퓨터로부터 accont/rate limit status(account/rate_limit_status) 콜을 만드십시오
    2. 왜 당신은 당신의 어플리케이션이 블랙리스트되었다고 생각하는지 설명하십시오.
    3. 어떻게 당신이 블랫리스팅을 일으킨 문제를 고쳤는지 기술하십시오
이 정보를 우리의 supprot folks(email to our support folks)로 보내주십시오, 그러면 당신은 다시 온라인 세계로 돌아올 수 있습니다.

vmware8버전에서 윈7 64비트 인스톨도중 뜨는 에러..
64비트 어쩌구...지원을 안한다고한다..
구글링결과 바이오스에서 설정을 바꿔주면된다

Cause:

The Virtualization Technology (VT) Extensions have not been enabled in the server BIOS.

Solution:

To install and configure 64bit operating systems in ESX Server requires that Virtualization Technology (VT) Extensions be enabled in the server BIOS settings.

HP DL580 G5 Example:

1) Enter the BIOS of the server by pressing F10 when prompted

2) Select Advanced Options…Processor Options

a. Intel(R) Virtualization Technology

i. Select Enabled

b. ESC

3) ESC

4) ESC

5) F10 to exit

6) Power Off Server

a. Required to enable Virtualization Technology

7) Power On Server

와우~

LG 로보킹에서 로보킹을 무료로

사용 해 볼수 있는 이벤트를 진행하네요.

그동안 위시리스트에만 올려놨던 로보킹을

직접 체험할 수 있는 절호의 기회 입니다. ^0^

7일동안 무료로 체험을 해 보고,

분양일기를 작성하면

완소 로보킹을 영원히 가질수도 있는데요.

이웃님들도 적극 첨여해 보세요.

로보킹 무료분양 받는 법!

가~장 마음에 드는 로보킹의 특징을 선택한 후,

간단한 글과 함께 무료체럼 신청을 하시면 됩니다.

LG 로보킹은요..

어두운 곳에서도 빠르고 꼼꼼하게 청소하구요.

초음파 센서가 장착되어 있어 장애물도 샤샤샥~

깜짝 놀랄만한 저소음으로 TV시청도 방해 받지 않고, 야간청소도 OK!

슬림한 바디는 소파ㅡ 침대 아래도 척척 청소할 수 있어요.

이웃님들은 로보킹의 어떤 점이 가장 마음에 드시나요?

궁금,궁금...

무료분양에 당첨되시면,

배송 받으시고, 사용 해 보신 후,

알아서 척척 회수 해 드리니

번거로움도 걱정 없습니다.

똑똑한 로보킹을 영원히 갖기 위한 노력!

7일동안 분양일기 쓰는 것도 놓치지 마시구요!!

모두모두 행운을 빌께요.

라잇나우~

지금 바로 신청하세요!!

* 무료분양 신청하기 +클릭

(1)ASCII(아스키 : American Standard Code for Information Interchange)

ANSI가 규정한 것으로, 컴퓨터에서 문자를 읽고 쓰기 위한 표준 방식. 영어 알파벳과 외국어 문자, 숫자, 구두점과 선택된 기호 등의 256자의 글자를 8비트 코드로 정의하고 있습니다.

8비트 중 7비트는 데이터 비트며 나머지 1비트는 패리티 체크 비트입니다. 대부분의 운영체제가 ASCII을 따르고 있지만, MS의 윈도우 NT만이 예외적으로 Unicode 표준을 사용합니다.

(2)Binary(바이너리)

2진수, 2진법 : 0과 1의 두 숫자만으로 수를 나타내는 표기 방법. 2를 기반으로 하는 숫자체계로 컴퓨터에서 데이터를 표현하기 위해 사용됩니다. 두 가지의 서로 다른 상태와 관련된 성질이나 특성입니다.

답변1)

바이너리나 아스키나 데이터 정보에 차이는 없습니다.
다만 전송 과정에서 아스키 방식으로 보내게 되면
각 데이터가 아스키 문자로 인식됩니다.
이 문자 중 일부는 윈도우와 유닉스 방식이 서로 다릅니다.
특히 행이 바뀜을 알리는 문자가 그렇죠.
정확치는 않습니다만 행이 바뀌는 곳 마다 행이 끝남을 알리는 문자가 추가되는것으로도 알고 있습니다(이건 추측입니다).
그래도 만일 전송하고자 하는 데이터가 텍스트 문서라면 크게 문제가 발생하지는 않습니다.
다만 그림이나 음악, 씨디 이미지 따위 아니 더 쉽게 말하면
txt문서가 아닌 모든 데이터는 아스키 방식으로 전송할 경우
위에서 말한 문자 정보가 포함되어 결국 데이터가 엉망이 되게 됩니다.
심지어 아래아 한글 문서나 워드 문서도 아스키 방식으로 보내서는 안됩니다.

텍스트문서를 바이너리로 보낼 경우에는 또 문제가 발생하지 않습니다.
그러니... 그냥 모조리 바이너리로 보내시기 바랍니다

출처 : 지식인

답변2)

아스키형식이나 바이너리형식이나 모두 바이너리형식으로 전송하면 큰 문제는 없습니다,

그럼에도 불구하고, 아스키형식의 전송방식이 남아있는 이유를 알려드리겠습니다.

우선 아스키방식에 대해 간단히 말씀드린다면,

일종의 약속으로 정의한, 기계어와 우리가 인식할 수 있는 문자의 연결집합입니다.

반면 바이너리는 코드라고하기도 뭣한 한마디로 0,1로 이루어진 기계어 자체입니다.

아스키코드는 7비트로 한개 문자를 표현하는 방식입니다.

1비트는 0과 1을 한묶음으로 하고있죠,

유사한 다른 코드들로는 ANSI 코드란것도 있구, 유니코드란 것도 있구, EBCDIC코드란

것도 있습니다.

즉 아스키코드는 우리가 문자를 입력하면 그 문자를 아스키코드를 이용해 기계어로 저장

해주고, 다시 그 기계어를 우리가 불러들이면 아스키 코드를 통해 우리가 볼수있는

문자로 보여주는 일종의 해석규약인 것입니다.

그럼 아스키 전송방식이란, 결국 아스키규약으로 정해진 기계어단위로 전송하는 방식인

것입니다. 이렇게 전송해도 그 파일이 아스키방식임을 먼저 알려주면, 받는쪽에서

7비트 단위로 끊어가며, 아스키방식으로 만들어진 파일로 저장하기 때문입니다. 그러면

전송된 파일을 다시 읽을때 받은쪽에선 아스키코드로 기계어를 해석해서 보여줍니다,

즉 제대로 전송된셈이지요, 물론 바이너리방식으로 전송해도 텍스트파일이 첫부분에

아스키방식으로 해석해야되는 파일이라는 정보를 보내주기때문에 상관은 없습니다.

그러나 아스키전송방식의 장점은 7비트단위의 규약에따라 보내기에 안정성과, 에러수정

작은 용량으로 빠른 전송을 할수있다는 장점이 있습니다. 또한 과거에는 아스키방식의

전송방식만 허용됬기때문에 (인터넷 초기시대) 그 관습이 남아있고, 그러한 방식만

지원하는 경우와 호환되도록 하기 위해 남아있기도 합니다.

바이너리 전송방식은 비트단위로 전송하며 중간에 정보손실이 있어도 그걸 유추보완

할수 없는 경우가 많습니다, 다시 전송받아야 된단 소리죠,, 그리고 대체로 텍스트파일에

비하면 상당히 많은 용량을 가지고 있습니다.