'Blog'에 해당되는 글 24건

  1. 2011.04.11 48/2(9+3) = 2 or 288
  2. 2011.03.23 [퍼온 글] 멸치의 비밀
  3. 2011.02.09 홀펀칭
  4. 2011.01.27 에버노트

 


한참 논쟁이 많은

수식 48/2(9+3)

이 수식에 정답은 2일 까요 288일까요 ㅋ

계산 방식의 차이다 수식이 잘못됬다

많은 의견들이 있습니다.

나도 처음에는 288이 맞는 답이라고 그냥 생각했었는데

48 / 2 * ( 9 + 3 )

48 / ( 9 * 2 + 3 * 2 )

이 둘중에 어느 수식이 맞느냐를 생각해 보고나니까

2가 정답이라고 생각드 드는군요

공부 담 쌓고 지낸지 오래됬지만

곱하기를 생략이 된 수식이지만 여기에 하나더

z / xy 처럼 곱하기가 생략된다면

괄호도 같이 생략된것 이기 때문이라고 생각되기 때문이죠

아래와 같이 값을 대입한다면

z = 1
x = 2
y = 3

1 / ( 2 * 3 ) 로 계산하지  1 / 2 * 3 로 계산 하지 않으니까요~

뭐 그렇다구요~

이게 정답인지 아닌지는 잘 모르겠지만.. ㅋㅋㅋ

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

다른 의견 하나 접수

48 / 2 ( 9 + 3 )

=> 48 / (2 * 9) + ( 2 * 3 )

=> 48 / 18 + 6

=> 2.6666... + 6

=> 8.6666...

왠지 이 의견도 끌리는 군요 =________=
 

TAG 2, 288
Posted by Requi 트랙백 0 : 댓글 0

댓글을 달아 주세요

* 이 글은 인터넷에 떠도는 루머일 뿐입니다.
* 사실 관계는 밝혀지지 않았으니 재미로만 감상하세요.

멸치는 청어목 멸치과다.

어릴적엔 가까운 수면 가까운 곳에 무리를 이룬다.

멸치는 어느정도 자라면 무리를 떠난다.  이때의 크기는 대략 10cm이다. 이떄부턴 생식이 가능하다.

멸치는 수명떄문에 죽었다는 기록이 없다.

그렇기떄문에 얼마나 자랄수 잇는지는 불분명하다.

가끔 어느정도 자란 대형멸치들이 무리를 지어 해안가에 나타나기도 한다.

대형멸치들은 육식이며 움직이는 속도와 힘은 상상을 초월한다.

 

미국 존 스켈톤 해양학박사는 자신이 3m가 넘는 멸치를 인도네시아에서 보았다고 주장하고 있다.

세계 여러 생물학자들도 멸치는 무한정으로 성장할수 있다고 언급한바 있다.

우리나라에서도 제주도에 가면 멸치후리기라는 노래가 있다.

옛날 대형멸치들이 배를 습격해 두려움을 담아 멸치를 내쫒기위해 만든노래이다.

멸치는 대륙봉해역에 살지만 1m가 넘으면 해구 근처에서 산다.

그래서 어떤 지질학자들은 지진의 원인은 엄청 큰 멸치가 맨틀의 대류를 방해하기 때문이라고 한다.


멸치가 3m가 넘어가면 진화에 가까운 변화를 보인다.

지느러미는 물의 마찰을 줄일수 있는 형태로 바뀌고 백상어를 능가하는 송곳니가 생긴다.

실제로 10m넘은 멸치는 육안으로 관측할수 없다.

너무 빠르게 움직이기 때문이다.

실제로 일본 잠수함이 이유없이 두동강난적이 있는데 학자들은 멸치의 소행이 유력하다고 전하고 있다.

Posted by Requi 트랙백 0 : 댓글 0

댓글을 달아 주세요

홀펀칭

2011.02.09 12:24 from 스크랩
 카페 > CPPWorld | 오호호
 http://cafe.naver.com/cppworld/1026
 

 


홀펀칭에 대해서 앞에서 조금 이야기를 했지만,
홀펀칭에서 가장 중요한 역할은, 바로 Server이다.
Server에서 각 Peer들에게 다른 Peer들의 정보를 제공해 줘야 하기 때문이다.

뭐 홀펀칭을 구현 하는 방법은 아주 다양하다.
Server에 UDP 패킷을 보내어, Server에서는 Connect된 Socket의 IP및 Port정보와
UDP 패킷으로 넘어온 정보를 비교하여, NAT에 속해 있는지 아닌지를 판별하는 곳도
있다고는 하는데, ( 뭐 그 효율은 안해봐서 모르겠다. )

우리는 그렇게 복잡하지 않은 방법을 설명하도록 하겠다.

원리는 간단하다.
Server는 각 peer들의 ip와 port를 알고 있다.
이러한 정보를 각 Peer들에게 보내주고, peer끼리 통신을 시도한후,
그 결과 값만 서버에게 보내주면 된다.
그리고 서버는 peer간의 통신이 이루어지지 않는 peer들에게만
패킷을 보내어 알려주기만 하면 되는 것이다.

순서는 다음과 같다.

1. Server에선 다른 Peer들의 정보를 peer에게 보내줌.
2. 제공 받은 다른 Peer들에게 UDP패킷을 보냄.
3. 다른 Peer들에게 UDP패킷을 받았다면 해당 peer와는 통신이 되었다고 판단.
4. 통신이 되지 않은 Peer들의 정보를 Server에게 보냄.
5. Server에서는 각 peer들의 통신이 되지 않은 peer들의 list를 작성.
6. 작성된 list를 토대로, 통신이 되지 않은 peer들의 정보를 각 peer들에게 보냄.


즉, 홀펀칭 자체는 크게 6단계로 나뉘며,
한가지씩 설명해보도록 하겠다.
그전에, 대기방에 총 4명의 User가 접속해 있다고 치고,
각 유저의 상황은 다음과 같다.

A. NAT에 속함.
B. NAT에 속하지 않음.
C. NAT에 속하지 않음.
D. NAT에 속하지 않음.

1. Server에선 다른 Peer들의 정보를 peer에게 보내줌.

네명의 Peer들에게 서로 다른 Peer들의 정보를 보내준다.
즉,

A 에게는 B, C, D
B 에게는 A, C, D
C 에게는 A, B, D
D 에게는 A, B, C


2. 제공 받은 다른 Peer들에게 UDP패킷을 보냄.

정보를 받은 Peer들은, 각기 제공 받은 peer들에게
UDP패킷을 보내어 자신의 존재를 알린다.

한 1초에서 2초 동안 패킷을 보내며 패킷을 받으면서
홀펀칭을 진행한다.

3. 다른 Peer들에게 UDP패킷을 받았다면 해당 peer와는 통신이 되었다고 판단.

보내면서 대기하던 중에 패킷이 도착하면,
자신이 가지고 있는 리스트에 있는 user인지를 검사하고,
없다면 잘못된 패킷으로 간주. 리스트에 있다면 해당 Peer와는 통신이 되었다고,
체크 하도록 한다.

보통 1초에 5~15번 사이로 보내는 것이 무난.

단, 이때 모든 Peer들에게 패킷을 받았다고 해서 절대로,
보내는 것을 중단해서는 아니된다.
나는 패킷을 받았지만 상대방은 받지 못한 상황이 될 수도 있기 때문이다.

4. 통신이 되지 않은 Peer들의 정보를 Server에게 보냄.

주어진 시간동안 통신을 시도하고,
리스트를 돌면서 체크 되지 않은 peer들의 정보를,
server에게 보낸다. 이때, 각 peer들의 고유 아이디등을 보내는 것이 제일 무난할 것이다.


5. Server에서는 각 peer들의 통신이 되지 않은 peer들의 list를 작성.

위의 상황에서 예상되는 결과는 다음과 같다.

A.  => B, C, D에게 패킷이 오지 않음
B.  => 오지 않은 Peer는 없음 ( A, C, D에게 패킷이 왔음 )
C.  => 오지 않은 Peer는 없음 ( A, B, D에게 패킷이 왔음 )
D.  => 오지 않은 Peer는 없음 ( A, B, C에게 패킷이 왔음 )


이때, 게임이 진행될 때,
A는, B, C, D 에게 UDP패킷을 보내고,
B, C, D는, A를 제외한 peer들에게 UDP패킷을 보내며,
A에 대해서는 릴레이 서버를 거쳐서 보내게 해야 할 것이다.

그렇기 때문에 서버에선 리스트를 받은 후 새로운 리스트를 작성해야 한다.
해당 peer가 준 리스트는 보낼수 없다는 정보가 아닌 받을 수 없다는 정보기 때문에,
이를 보내지 않아도 된다는 리스트로 바꿔야 하기 때문이다.

보내도 받지를 못하는게 peer에서 보내는 것은 낭비이기 때문이다.
또한, 서버로부터 온 패킷을 중계 할때도, 받지 못한 peer에게만 주어야
서버에서의 낭비도 줄테니 말이다.

즉, 위의 리스트를 아래와 같이 바꾸어야 한다.

A. => 보낼 수 없는 Peer는 없음
B. => A에게 보낼 수 없음.
C. => A에게 보낼 수 없음.
D. => A에게 보낼 수 없음.

방법은 간단하다.
각 Peer의 리스트를 돌면서 패킷이 오지 않은 peer의 새로운 리스트에 자신을 추가하면된다.

// 해당 Peer를 검사.
for( int i = 0 ; i < GetRecvListCount() ; i++ )
{
  GetRecvPeer( i )->AddNode( this );
} //for

이렇게 각 Peer들에게 실시하면,
위의 리스트를 작성 할 수 있다.

6. 작성된 list를 토대로, 통신이 되지 않은 peer들의 정보를 각 peer들에게 보냄.

위에서 작성된 리스트에 한명이라도, Node가 존재하게 되면,
서버는 해당 Peer에게 서버에 패킷을 보내도록 패킷을 보낸다.

그리고 이후에 해당 peer에게 패킷이 오게 되면,
위의 리스트에 등록된 peer들에게만 패킷을 주면 완료.



위와 같이 간단한 상황이 아닌, 좀더 복잡한 상황에 대해서 검사해 보자.

A. NAT에 속함
B. NAT에 속함 ( A와 같은 NAT )
C. NAT에 속하지 않음
D. NAT에 속함 ( A와 같지 않은 NAT )

먼저 위의 경우 예상되는 첫번째 리스트.

A. => C, D로부터 패킷이 오지 않음 ( B로 부터 패킷을 받음. )
B. => C, D로부터 패킷이 오지 않음 ( A로 부터 패킷을 받음 )
C. => 오지 않은 패킷은 없음 ( A, B, D 로 부터 패킷을 받음 )
D. => A,B, C로부터 패킷이 오지 않음

그리고 서버에서 재 작성된 두번째 리스트.

A => D에게 패킷을 보낼수 없음.
B => D에게 패킷을 보낼수 없음.
C => A, B, D에게 패킷을 보낼 수 없음.
D => A, B에게 패킷을 보낼수 없음

이때, 게임중에
A는 B, C에게 P2P패킷을 보내며,
B는, A, C에게 P2P패킷을...
C는, 서버에게 패킷을...
D는, C에게만 패킷을 보내게 된다.

이때, A, B, C, D는 모두 서버에게 패킷을 보내며,
서버에선

A에게 패킷이 왔을 경우 -> D에게 패킷을 전달
B에게 패킷이 왔을 경우 -> D에게 패킷을 전달
C에게 패킷이 왔을 경우 -> A, B, D에게 패킷을 전달
D에게 패킷이 왔을 경우 -> A, B에게 패킷을 전달

을 하게 된다.
이러한 상황에서도 무난하게 통신이 이루어짐을 알 수 있다.

원문 : http://narew.net/blog/36


Posted by Requi 트랙백 0 : 댓글 0

댓글을 달아 주세요

에버노트

2011.01.27 11:41 from 정보/소프트웨어

에버노트


1. 간단한 메모 및 문서작성이 가능하다

2. 웹에 그 내용이 저장되어 따로 저장하여 보관하지 않아도 어디서든 작업이 가능하다.

3. PC버전과 안드로이드 어플 버전이 있다.

4. http://www.evernote.com/ 무료 다운로드

5. 로그인
ID가 아직 없는 상태라면 중간에 무료 계정 만들기를 통하여 계정을 생성할 수 있다.

( 사진 클릭 시 원본사이즈로 확대 )



6. 회원 가입
실명, 이메일주소, ID, Pwd 만 입력하면 가입이 되므로 매우 간단하다~!!
( 사진 클릭 시 원본사이즈로 확대 )


7. 화면 구성
메뉴, 대분류, 소분류, 내용
( 사진 클릭 시 원본사이즈로 확대 )

노트북 = 대분류 폴더
노트 = 메모


메뉴 ( 추가 삭제 기타등등 문서 편집 하는 기능들 나열 되있음 )  
대분류
( 태그나 검색으로 노트를
찾거나 모와둘 수 있으며
유저가 편한데로 노트를
분류 할 수도 있다. )
소분류
( 노트의 제목, 생성날짜,
문서의 레이아웃을
볼 수 있으며 단어 단위로
검색이 가능하다. )
내용
( 문서 작성을 하는 공간
위 그림과 같이 다양한 서식과
하이퍼링크도 넣을 수 있으며
어지간한 문서 툴만큼의
퀄리티를 표현할 수 있다 =_= )

아직 핸드폰이랑 연동도 안해봤고 사용기간도 짧았지만 정리도 쉽게 되고

문서작성 퀄리티도 만족스러운 편이라 자주 애용할 예정이구요

아웃룩으로 일정과 메일을 관리하시던 분들은 매우 만족하실꺼 같습니다.

Posted by Requi 트랙백 0 : 댓글 0

댓글을 달아 주세요