549
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: + + + + + + + + + + + + + + + + + +
no edit summary
The 3DS software stack follows a server/client architecture, where common functionality is provided by global server processes through interfaces called ''ports'' and ''services''. Applications can access this functionality by creating ''sessions'' to the provided services. Technically, this is implemented using ''interprocess communication'' (IPC).
= Concepts =
== Ports ==
Ports are globally accessible points exposed by the server using CreatePort. Clients can start IPC sessions by connect to a server through a port using ConnectToPort. On the client-side, a port is identified by a fixed string, while on the server-side it is represented by a kernel handle using which the server can wait for incoming connections (using svcWaitSynchronization on that handle).
== Services ==
Services are anonymous ports: They can not be connected to through ConnectToPort because they don't have any name recognized by that function. Instead, a service is registered to the [[Services|service manager]] port ("srv:") using the IPC command RegisterService. Clients then open sessions to services using the service manager command GetServiceHandle.
== Sessions ==
Sessions are communication channels opened on a specific port. Clients use their session handle to send [[#IPC_Command_Structure|IPC commands]] to the server using SendSyncRequest, while servers use ReplyAndReceive to reply. In both cases, the kernel takes care of transferring IPC command data from the [[Thread_Local_Storage|TLS]] of the sending process to the TLS of the receiving process.
= Command Structure =
IPC commands are written to the [[Thread Local Storage]] at offset 0x80 and submitted using [[SVC|svcSendSyncRequest]]. If the kernel was able to dispatch the request, the server reply will be written to TLS+0x80. Often the second word of the response data is the error code (or 0 if success).
IPC commands are written to the [[Thread Local Storage]] at offset 0x80 and submitted using [[SVC|svcSendSyncRequest]]. If the kernel was able to dispatch the request, the server reply will be written to TLS+0x80. Often the second word of the response data is the error code (or 0 if success).