이번 강좌에서는 서버에서 클라이언트로, 클라이언트에서 서버로 메시지를 보내는 방법을 배워봅시다.
사실 지난번 강좌에서 클라이언트에서 서버로 메시지를 보내는 방법은 배웠었습니다.
지난번 강좌에 알람에서 서버의 생존체크를 하던 그 코드가 바로 메시지를 보내는 코드였는데, 이번에는 심화해서 배워볼 겁니다.
이번에 만드는 접속 코드는 지난번과는 조금 다릅니다.
일단 메시지를 보내는 버퍼는 서버일 때나 클라이언트일 때나 둘 다 생성하고요, 서버는 ds_list 로 플레이어들을 저장합니다.
왜 지난번처럼 ds_map 이 아닌 ds_list 로 처리하느냐면, 이 구조체가 클라이언트들에게 메시지를 보낼 때 가장 효율적이기 때문입니다.
메시지를 보낼 때에도 조건이 필요하겠죠?
키보드를 누를 때 메시지를 보내도록 해봅시다.
클라이언트는 다른 클라이언트에게 직접 메시지를 보낼 수가 없습니다.
혹시라도 보내고자 한다면 '클라이언트->서버->클라이언트' 순서를 거쳐야 하지요.
결국, 메시지는 서버로만 보내게 되는데, 그래서 network_create_socket 할 때에 받은 소켓으로 메시지를 보내면 서버에게 보내집니다.
하지만 서버는 클라이언트 다수를 대상으로 합니다.
그래서 network_create_server 로 받은 소켓으로 메시지를 보내면 대상이 모호하지요.
그렇기 때문에 ds_map_find_value(async_load, "socket") 으로 받은 플레이어의 소켓 id 를 통해서 메시지를 보내게 됩니다.
위 코드는 서버일 때와 클라이언트일 때를 구분해서 메시지를 보냅니다.
서버일 때에는 ds_list 에 저장된 플레이어의 소켓 id 를 통해서 메시지를 전달하는 게 보이실 겁니다.
-
buffer_s8(byte), buffer_s16(short), buffer_s32(int) 등은 자료형을 의미합니다.
이러한 자료형은 변수가 저장될 그릇을 설정하는데, 그중에서 buffer_u8 등 u가 들어간 것은 unsigned 자료형을 의미합니다.
자료형의 범위는 인터넷에 잘 나와 있습니다.
-
위에서
buffer_write(buffer, buffer_u8, 1)
buffer_write(buffer, buffer_string, "클라이언트의 메시지.")
버퍼에 숫자를 먼저 저장한 뒤에 실질적인 내용을 보내는 것을 보실 수가 있습니다.
이것은 아주 중요한 개념입니다.
전에 알람에서 서버의 생존 확인을 할 때에 buffer_write(buffer, buffer_u8, 0) 을 썼었습니다.
이러한 숫자의 구별은 메시지를 구별하는 역할을 해줍니다. (보통 메시지 id 라고 불립니다.)
예를 들어 엄마가 500원을 주고 음료수를 사와 라고 하면 어떤 음료수를 사와야 하는지 모를 것입니다.
하지만 콜라를 사와 사이다를 사와 등 직접적인 언급을 하면 음료수를 구입하기가 쉽게 됩니다.
이처럼 메시지 앞에 붙이는 숫자는 이 메시지가 어떤 명령을 하는 메시지인지를 알기 쉽게 해줍니다.
그러니까 현재 제 강좌에서 메시지 id 0 은 서버의 생존 확인을,
메시지 id 1 은 문자열 메시지의 전송을 의미하겠네요.
이제 네트워킹 이벤트로 메시지를 받아봅시다.
혹시라도 메시지의 전달 원리가 아직도 모호하시다면 http://o.playgm.co.kr/316 링크도 참조해주시면 좋습니다.
서버는 network_type_connect, network_type_disconnect 를 통해서 플레이어의 리스트를 관리합니다.
network_type_data 는 서버와 클라이언트 모두가 받는 아까 보낸 메시지를 관리합니다.
아까 메시지 id 를 1로 보내고, 그 뒤에 문자열을 보냈으니 case 1: 에서 처리하는 것을 보실 수가 있을 것입니다.
또 버퍼를 읽을 때에는 buffer_write 를 한 순서대로 buffer_read 를 하는 것도 보실 수가 있습니다.
이제 알람에서 서버의 생존 확인만 하면 기본적인 메시지를 보내는 베이스가 완성된 것입니다.
여기서 buffer_write(buffer, buffer_u8, 0) 으로 메시지 id 를 0으로 보내는 것도 확인하실 수가 있습니다.
Networking Example 2.gmz
