Mailslots are designed around the Windows file system interface. Client and server applications use standard Win32 file system I/O functions, such as ReadFile and WriteFile, to send and receive data on a mailslot and take advantage of Win32 file system naming conventions. Mailslots rely on the Windows redirector to create and identify mailslots using a file system named the Mailslot File System (MSFS). Chapter 2 described the Windows redirector in greater detail.
Mailslots use the following naming convention for identification:
\\server\Mailslot\[path]name |
The string above is divided into three portions: \\server, \Mailslot, and \[path]name. The first string portion, \\server, represents the name of the server on which a mailslot is created and on which a server application is running. The second portion, \Mailslot, is a hardcoded mandatory string for notifying the system that this filename belongs to MSFS. The third portion, \[path]name, allows applications to uniquely define and identify a mailslot name; the path portion might specify multiple levels of directories. For example, the following types of names are legal for identifying a mailslot:
\\Oreo\Mailslot\Mymailslot \\Testserver\Mailslot\Cooldirectory\Funtest\Anothermailslot \\.\Mailslot\Easymailslot \\*\Mailslot\Myslot |
The server string portion can be represented as a dot (.), an asterisk (*), a domain name, or a server name. A domain is simply a group of workstations and servers that share a common group name. We'll examine mailslot names in greater detail later in this chapter, when we cover implementation details of a simple client.
Because mailslots rely on the Windows file system services for creation and transferring data over a network, the interface protocol is independent. When creating your application, you don't have to worry about the details of underlying network transport protocols to form communications among processes across a network. When mailslots communicate remotely to computers across a network, the Windows file system services rely on the Windows redirector to send data from a client to a server using the Server Message Block (SMB) protocol. Messages are typically sent via connectionless transfers, but you can force the Windows redirector to use connection-oriented transfers on Windows NT and Windows 2000, depending on the size of your message.
Mailslots normally use datagrams to transmit messages over a network. Datagrams are small packets of data that are transmitted over a network in a connectionless manner. Connectionless transmission means that each data packet is sent to a recipient without packet acknowledgment. This is unreliable data transmission, which is bad in that you cannot guarantee message delivery. However, connectionless transmission does give you the capability to broadcast a message from one client to many servers. The exception to this occurs on Windows NT and Windows 2000 when messages exceed 424 bytes.
On Windows NT and Windows 2000, messages larger than 426 bytes are transferred using a connection-oriented protocol over an SMB session instead of using datagrams. This allows large messages to be transferred reliably and efficiently. However, you lose the ability to broadcast a message from a client to many servers. Connection-oriented transfers are limited to one-to-one communication: one client to one server. Connection-oriented transfers normally provide reliable guaranteed delivery of data between processes, but the mailslot interface on Windows NT and Windows 2000 does not guarantee that a message will actually be written to a mailslot. For example, if you send a large message from a client to a server that does not exist on a network, the mailslot interface does not tell your client application that it failed to submit data to the server. Since Windows NT and Windows 2000 change their transmission method based on message size, an interoperability problem occurs when you send large messages between a machine running Windows NT or Windows 2000 and a machine running Windows 95 or Windows 98.
Windows 95 and Windows 98 deliver messages via datagrams only, regardless of message size. If a Windows 95 or Windows 98 client attempts to send a message larger than 424 bytes to a Windows NT or Windows 2000 server, Windows NT and Windows 2000 accept the first 424 bytes and truncate the remaining data. Windows NT and Windows 2000 expect larger messages to be sent over a connection-oriented SMB session. A similar problem exists in transferring messages from a Windows NT or Windows 2000 client to a Windows 95 or Windows 98 server. Remember that Windows 95 and Windows 98 receive data via datagrams only. Because Windows NT and Windows 2000 transfer data via datagrams for messages 426 bytes or smaller, Windows 95 and Windows 98 cannot receive messages larger than 426 bytes from such clients. Table 3-1 outlines these message size limitations in detail.
NOTE
Windows CE was intentionally left out of Table 3-1 because the mailslot-programming interface is not available. Also note that messages sized 425 to 426 bytes are not listed in this table due to a Windows NT and Windows 2000 redirector limitation.
Table 3-1. Mailslot message size limitations
Transfer Direction | Connectionless Transfer via Datagrams | Connection-Oriented Transfer |
---|---|---|
Windows 95 or Windows 98 -> Windows 95 or Windows 98 | Message size up to 64 KB. | Not supported |
Windows NT or Windows 2000 -> Windows NT or Windows 2000 | Messages must be 424 bytes or less. | Messages must be greater than 426 bytes |
Windows NT or Windows 2000 -> Windows 95 or Windows 98 | Messages must be 424 bytes or less. | Not supported |
Windows 95 or Windows 98 -> Windows NT or Windows 2000 | Messages must be 424 bytes or less; otherwise, the message is truncated. | Not supported |
Another limitation of Windows NT and Windows 2000 is worth discussion because it affects datagram data transmissions. The Windows NT and Windows 2000 redirector cannot send or receive a complete datagram message sized 425 or 426 bytes. For example, if you send out a message from a Windows NT or Windows 2000 client to a Windows 95, Windows 98, Windows NT, or Windows 2000 server, the Windows NT redirector truncates the message to 424 bytes before the sending it to the destination server.
To accomplish total interoperability among all Windows platforms, we strongly recommend limiting message sizes to 424 bytes or less. If you are looking for connection-oriented transfers, consider using named pipes instead of mailslots. Named pipes are covered in Chapter 4.
When you build a mailslot client or server application using Microsoft Visual C++, your application must include the Winbase.h include file in your program files. If you include Windows.h (as most applications do) you can omit Winbase.h. Your application is also responsible for linking with Kernel32.lib, which is typically configured with the Visual C++ linker flags.
All Win32 API functions that are used in developing mailslot client and server applications (except for CreateFile and CreateMailslot) return the value 0 when they fail. The CreateFile and CreateMailslot API functions return INVALID_HANDLE_VALUE. When these API functions fail, applications should call the GetLastError function to retrieve specific information about the failure. For a complete list of error codes, see the standard Windows error codes in Appendix C or consult the header file Winerror.h.