| CIFS supports two kinds of Mailslots: Class 1: Reliable Class 1 Mailslots are a whole heck of a lot like Named Pipes. Class 1 messages are packed into an SMBtrans SMB, and then sent across the network using TCP. The only real difference is that Class 1 Mailslot calls indicate only success or failure. They do not return any other results. We won't be paying any attention to Class 1 Mailslots, because they are not used by the Browse Service. Class 2: Unreliable and Broadcast Class 2 Mailslots are a whole 'nother kettle of bananafish. On the surface, they look like Named Pipes and Class 1 Mailslots, but that's just because the interface was designed to be somewhat consistent. Below the surface, Class 2 Mailslot messages are sent using the NBT Datagram Service. That means that the underlying transport is UDP, not TCP. It also means that Class 2 Mailslot messages can be broadcast or multicast to the local LAN. Another difference is that Class 2 Mailslot messages are simply sent. No result (success, failure, or otherwise ) is returned. Mailslots, like Named Pipes, exist within the IPC$ share. Mailslot names have a familiar format, as shown below. \MAILSLOT\ mailslotname The general form of a Mailslot name . Similar to the convention used for Named Pipes. \MAILSLOT\BROWSE The Mailslot name used by the Windows NT Browse Service. \MAILSLOT\LANMAN The Mailslot name used by the older LAN Manager Browse Service. The Browse Service uses Class 2 Mailslots extensively. With the exception of the NetServerEnum2 RAP call, all Browse Service announcements and requests are sent using Class 2 Mailslots. In general, if the destination is local, a Browse Service Mailslot message will be sent as a broadcast at the IP level. Unicast UDP datagrams are used if the destination is on a remote subnet (e.g., a remote DMB). Broadcast messages that contain an NBT group name in the DESTINATION_NAME field are considered Multicast at the NBT level. If the DESTINATION_NAME is unique, the message may still be broadcast to avoid the need to resolve the name using the NBT Name Service. As suggested in Figure 21.2, the receiver of a broadcast datagram should discard the message if it is not listening on the DESTINATION_NAME or the given Mailslot name. Figure 21.2. Class 2 Mailslots Class 2 Mailslot messages may be broadcast, multicast (NBT group), or unicast. If a message is sent as a broadcast or multicast datagram, all of the NBT nodes on the LAN will receive it. Those that are not listening on the specified Mailslot ( \MAILSLOT\MEGAPHONE , in this case) or on the specified NBT name should discard it.  Class 2 Mailslot messages are kind of quirky. Even though they use the NBT Datagram Service, they are formatted as SMB_COM_TRANSACTION (that is, SMBtrans) messages. That's right: SMB over UDP. Go figure. This may be the result of someone being overly enthusiastic about reusing existing code. In any case, it means that we will be learning how to format an SMBtrans message. It's Not a Bug It's a Feature Alert  | The one-way nature of Mailslot messages has an interesting side-effect, which is this: All Browse Service Mailslot messages are sent to UDP port 138 . The reason for this seemingly incorrect behavior is that the receiver's response to a Mailslot message is not really a reply. It is a "response" in the sense of "stimulus-response." When a browser node receives one of the Browse Service Mailslot Messages, it may react by sending messages of its own. In many cases, those messages must be multicast to a NetBIOS group name, so sending them to the source port of the original "stimulus" datagram would simply not work. (You're getting to love this stuff, aren't you... ) The upshot is that the only way to properly implement the Browse Service (and Class 2 Mailslots in general) is to run a daemon that listens on UDP/138 . |
| 