멀티유저 엑스트라가 멀티유저 서버에 접속할 때, 먼저 TCP/IP 연결을 구축한다. 이것이 성공하면 클라이언트와 서버는 서버가 로그온을 인증하고 응답을 보내도록하기 위한 메세지들을 교환한다.

만약 클라이언트와 서버가 UDP로 설정되어있다면, 로그온 패킷내에 서버로 전송하는 추가적인 정보들과 서버에서 클라이언트로 보내어지는 UDP 주소 정보를 가진 추가적인 패킷이 존재하게 된다.

클라이언트와 서버간에 보내어지는 데이타는 다중 TCP/IP 블럭들로 간주될 수 있다. 모든 데이타는 네트워크 바이트 순서로 보내어진다. (비인텔 기반)

클라이언트와 서버간에 전달되는, 또는 피어 클라이언트간에 전송되는 메세지들은 모두 같은 포맷을 가진다:

요소	바이트단위의 크기	설명
Header tag	2	"r" + 널 바이트
Message Size	4	전체 메세지 바이트 크기
Error code	4	정수형의 에러코드
Time stamp	4	서버가 메세지를 다루었을 당시의 정수형 밀리초단위의 타임 스탬프
Subject	string	다양한 메세지 주제를 나타내는 문자열
Sender ID	가변	메세지를 보낸 이의 사용자 ID를 나타내는 문자열
Recipient String List	가변	수령자의 목록
Contents	가변	메세지 내용을 나타내는 값(들)

모든 정수(에러코드나 타임 스템프와 같은)는 32비트이고 네트워크 바이트 순서로 저장된다. (다시 강조하지만 비인텔 기반이다)

<subject string>, <sender ID>, 그리고 문자열(string)들은 일반적으로 다음과 같이 인코딩된다.

<data size>	문자열 길이(4바이트)
<string data>	문자열 데이타. 널로 끝나지 않는다. 다만, 짝수 바이트 경계를 맞추기위해 덧붙임은 있을 수 있다. (N 바이트)

<recipient string list>와 다른 문자열 리스트들은 다음과 같이 인코딩된다:

<number of strings>	리스트에 존재하는 문자열 개수(4 바이트)
<string data>	N개의 문자열(string)들

보내기/받기 양쪽모두, <content> 섹션은 링고 값으로 인코딩된 이진 스트림이다. 어쨌든 이 값은 각 타입에 따라 다르게 인코딩되어지지만, 각 값은 값의 타입을 나타내는 태그로 시작한다. 가변적인 바이트길이를 가지는 섹션들은 짝수 바이트 경계를 맞추기위해 추가 바이트가 첨부될 수 있다.

링고 값들은 각각의 데이타 타입에 따른 2 바이트 타입 식별자과 함께 인코딩된다. 타입 식별자는 네트워크 바이트 순서로 저장된다. 다음 테이블은 타입과 데이타의 종류를 보여준다:

C++ 타입 식별자(mmtypes.h)	값	데이타
kMoaMmValueType_Void	0	인코딩 된 데이타가 없거나 추가적인 데이타가 없음
kMoaMmValueType_Integer	1	네트워크 바이트 순서로 된 4 바이트 정수
kMoaMmValueType_Symbol	2	문자열 길이를 나타내는 4 바이트 + 문자열 데이타를 나타내는 N 바이트로 구성. 널로 끝나지 않으며, 짝수 바이트 경계를 맞추기위해 추가적인 널데이타가 붙을 수 있다.
kMoaMmValueType_String	3	문자열 길이를 나타내는 4 바이트 + 문자열 데이타를 나타내는 N 바이트로 구성. 널로 끝나지 않으며, 짝수 바이트 경계를 맞추기위해 추가적인 널데이타가 붙을 수 있다.
kMoaMmValueType_Picture	5	길이를 나타내는 4 바이트 + 그림 데이타를 나타내는 N 바이트로 구성. 짝수 바이트 경계를 맞추기위해 추가적인 널데이타가 붙을 수 있다.
kMoaMmValueType_Float	6	네트워크 바이트 순서로 된 8 바이트 실수
kMoaMmValueType_List	7	리스트 요소의 개수 4바이트 + N개의 값(들)
kMoaMmValueType_Point	8	2개의 수치값으로 구성. 각각은 float나 integer가 될 수 있다. 첫번째는 X, 후자는 Y.
kMoaMmValueType_Rect	9	4개의 수치값으로 구성. 각각은 float나 integer가 될 수 있다. 첫번째부터 top, left, bottom, right
kMoaMmValueType_PropList	10	리스트 요소의 개수 4바이트 + 한 쌍을 이루는 값(들)이 N개. 각 쌍의 첫번째 요소는 symbol이며, 그다음은 해당되는 값을 나타낸다.
kMoaMmValueType_Color	18	이진 데이타. 4바이트.
kMoaMmValueType_Date	19	이진 데이타. 16바이트.
kMoaMmValueType_Media	20	데이타 길이 4바이트 + 이진 미디어 데이타 N 바이트. 짝수 바이트 경계를 맞추기위해 추가적인 널데이타가 붙을 수 있다.
kMoaMmValueType_3dVector	22	3개의 float 값으로 구성.(각각 8 바이트. 전체 24바이트.). 네트워크 바이트 순서.
kMoaMmValueType_3dTransform	23	16개의 float 값으로 구성.(각각 8 바이트. 전체 128바이트.). 네트워크 바이트 순서.

로그온 과정은 연결을 구축하기 위한 클라이언트와 서버(또는 피어 호스트)간의 특별한 메세지 교환이다. 일단 TCP/IP 접속이 받아들여지면(accept), 클라이언트는 서버로 메세지를 보낸다. 그러면 서버는 클라이언트에게 응답 메세지를 보낸다. 서버로부터 이 메세지를 받은 이후, 클라이언트 엑스트라는 ConnectToNetServer 메세지를 링고로 보내게 된다.

서버로 보내어지는 로그온 메세지는 2개의 다른 포맷으로 보내는 것이 가능하다. 첫번째는 원래의 멀티유저 엑스크라에 의해 사용되는 것이고, 두번재는 후속 버젼에서 추가된 더 많은 기능들을 지원하기 위해 개발되어졌다.

로그온 패킷의 content 부분은 인코딩될 것이다. 아래의 Encryption에 대한 내용을 참조하라.

If the client and server are set up for UDP traffic, and the user's logon is accepted, the server will send a message to the client with information about server's UDP configuration. This message tells the client where to send UDP packets. This message is sent before the server confirms the logon has succeeded. The client xtra processes this message; it is never seen by the Lingo programmer.

This message contains:

Message component	Data
errorCode	0
subject string	Will be "udp"
content	Contains a list with two strings

Content List Item	Data
First item	A string with the UDP address and port that the client sends UDP packets to. Something like "123.45.67.89:1743"
Second item	UDP cookie - a string representation of an integer that the client sends with each UDP packet

The server or peer host will reply to a logon message with a message containing the following information:

Message component	Description
errorCode	Contains the result of the logon request, 0 for no error
subject string	Will be "Logon"
recipient string list	Will be the user's ID
content	Will be a single string containing the movie name

When the client xtra receives this packet, it sends a "ConnectToNetServer" message back to the Lingo script indicating the connection attempt has finished.

Token-based logon support is a minor tweak to the logon sequence that was added for version 1.0.2. This is to support token-based indentification when switching between movies.

The token is supplied to the Director movie via an HTML embed tag. The movie then does the logon (calls ConnectToNetServer()) with a userID of "#token" (a string) and the password as a string containing the token. This is passed without alteration to the server.

The server will reply to the logon, but the xtra will change its userID to the recipient of the incoming message if it did a token-based logon. Thus the server informs the xtra of it's real user name. The movie author must also recognize the user name from the recipient of the "ConnectToNetServer" reply message.

The token-based logon sequence does not change the protocol or the logon sequence, except that xtra and movie switch their userID to match the server's reply in the logon sequence.

클라이언트에서 서버로 보내어지는 로그온 패킷은 암호화된 content를 담고 있다. 데이타는 디폴트 키로써 "IP주소 resolution"을 적용한 Blowfish 알고리즘을 사용하여 암호화 된다.

만약 특별한 암호화 키인 "#NoEncryption"이 사용되면 로그온 패킷은 암호화되지 않는다.

만약 암호 키가 "#All"접두어를 가진 사용자에 의해 정의되었다면, 모든 패킷이 암호화된다. 이 경우는, 키는 "#All"접두어를 없음으로서 얻을 수 있는 사용자에 의해 제공된 키가 된다.

If the user supplies an encryption key less than 20 bytes long, the user's key is appended with the string "IPAddress resolution" and used as the full Blowfish key.

UDP messages have the same structure as TCP/IP messages.

When the client sends a UDP packet to the server, it must be sent using the address and port that was exchanged with the server during the logon process. The client must also put the "UDP cookie" into the timestamp slot of the message. This cookie was also sent from the server to the client during the logon exchange.