The SDK includes a sample transport service. For a description of this sample, see Windows CE Sample Applications in the online Help. This Svcsampl sample transport service performs message service routines, such as creating, writing to, and reading from files that are located in the Inbox folder. This is performed, for demonstration purposes, using file system functions, such as CreateFile, ReadFile, and WriteFile. For transport functions that perform such tasks as sending, receiving, and deleting messages, a handle to a MailMsg structure is passed. The MailMsg structure contains the message header and body, and information about the message.
The sample transport service provided with the SDK sample code allocates a local heap in TransportInit for a transport-defined SERVICE structure. This structure supports handling the messages and provides a number of service functions that you can use for message handling. For example, the sample service locates messages in a mail directory specified by the szMailDir member of the SERVICE structure. These messages are stored as individual text files; file names are numbers with a .txt suffix, assigned in sequence.
Every mail message that arrives on a server is given a persistent unique ID. The system guarantees that this ID is different for every mail message and that it never changes. However, because these IDs are long—up to 70 characters— and are not convenient to use inside the transport service, Windows CE provides an alternative. For each session, the service generates a non-persistent session ID to reference a long unique ID. Each time a connection is made to the server —that is, each time a POP3 session is created — the server looks at all of the currently stored messages and assigns a session ID to each message. The messages are numbered from one through the total number of messages. This makes it easier to reference a particular message without having to use its long unique ID. The drawback is that you have no guarantee that message number five on this session with a session ID of five will still be message number five the next time the service is connected. Because of this, the session ID can not be trusted from one connection of a service to the next connection of that service.