254
edits
Changes
→Concepts
== Sessions ==
== Sessions ==
Sessions are communication channels consisting of a client and server, through which data can be exchanged in the form of a request and response, respectively. Through sessions, the standard [[#Command Structure|IPC command protocol]] is implemented. Clients use their client session handle to send IPC commands to the server using svcSendSyncRequest, while servers use svcReplyAndReceive to reply. In both cases, the kernel takes care of transferring IPC command data from the [[Thread Local Storage]] of the sending process to the TLS of the receiving process. Sessions can be created through svcCreateSession, which provides the caller with the client and server handles. These are used in their raw form to implement [[Filesystem services#File service|file handles]].
Sessions are communication channels consisting of a client and server, through which data can be exchanged in the form of a request and response, respectively. Through sessions, the standard [[#Command Structure|IPC command protocol]] is implemented. Clients use their client session handle to send IPC commands to the server using svcSendSyncRequest, while servers use svcReplyAndReceive to reply. In both cases, the kernel takes care of transferring IPC command data from the [[Thread Local Storage]] of the sending process to the TLS of the receiving process. Sessions can be created through svcCreateSession, which provides the caller with the client and server handles.
Sessions are used in their raw form to implement [[Filesystem services#File service|file handles]].
== Ports ==
== Ports ==
Services are an abstraction of ports that are managed by service manager. Services cannot be connected to through svcConnectToPort, as the underlying port is a private port. The service name is instead entirely handled by service manager, and the kernel is not aware of it. Clients are instead expected to open a session to a service using the "srv:" port command [[SRV:GetServiceHandle|GetServiceHandle]]. The client process must pass an access permission check for each service (by name) that it attempts to request a session with. These permissions are granted in the "service access control" of the title's [[NCCH/Extended Header#ARM11 Local System Capabilities|extended header]]. A service is registered with service manager using the command [[SRV:RegisterService|RegisterService]].
Services are an abstraction of ports that are managed by service manager. Services cannot be connected to through svcConnectToPort, as the underlying port is a private port. The service name is instead entirely handled by service manager, and the kernel is not aware of it. Clients are instead expected to open a session to a service using the "srv:" port command [[SRV:GetServiceHandle|GetServiceHandle]]. The client process must pass an access permission check for each service (by name) that it attempts to request a session with. These permissions are granted in the "service access control" of the title's [[NCCH/Extended Header#ARM11 Local System Capabilities|extended header]]. A service is registered with service manager using the command [[SRV:RegisterService|RegisterService]].
Internally, service manager creates services by creating a private port which it associates with the desired service name. To create sessions to a service on behalf of a client, service manager uses svcCreateSessionToPort, passing the port handle it obtained when creating the port, to the kernel. Service manager then returns the resulting session handle to the client in the GetServiceHandle response.
The majority of 3DS inter-process communication is implemented as services.
The majority of 3DS inter-process communication is implemented as services.