 |
OWLNext 7.0
Borland's Object Windows Library for the modern age
|
|
OWLNext 7.0
Borland's Object Windows Library for the modern age
|
The TSocket class has a couple different notification options that you can use.
First, we'll give a brief description of how Winsock notification works. Then we'll talk about how it works with the Socket class and your options. A blocking socket causes read, write, etc. calls to sometimes block the executing thread until the call has completed, depending on whether the Winsock driver is ready to make the call. You cannot know for sure if any given socket read or write call will make the socket block or not.
Winsock provides a way for you to be notified by Winsock when it is ready to make a read or write call without blocking: you call the Winsock function WSAAsyncSelect() to tell Winsock to notify you (you supply an HWND) with FD_READ, FD_WRITE, FD_OOB, FD_ACCEPT, FD_CONNECT, FD_CLOSE identifiers. For example, when Winsock is ready to accept read calls on the socket, it sends your HWND an FD_READ message. If you don't call WSAAsyncSelect(), then all socket functions you use will block.
The OWLSock TSocket class has both an internal notification mechanism and an external notification mechanism. In the internal mechanism, TSocket has an internal hidden friend window that receives all FD_XXX notifications. With the external notification mechanism, you tell the TSocket class that you want all FD_XXX notifications to go to the window of your choice. These two internal and external notification systems are mutually exclusive. The TSocket class uses internal notification by default, but you can redirect any of the notifications to a given window.
In the Windows Socket Classes, the equivalent Socket functions to WSAAsyncSelect() are DoAcceptNotification() and DoRegularNotification(). These two functions cause a socket to be notified of FD_ACCEPT and all other FD's, respectively. Since a listening socket can do nothing else in life but listen, and a connected (read/write) socket can never be a listening socket, we have a separate functions to turn on both of the notification types.
When TSocket gets an internal notification, it calls the appropriate DoXNotification() function. In the TSocket class, these functions are empty, while the TStreamSocket and TDatagramSocket classes do an appropriate action based on the message. You can subclass the TSocket class (or more likely, the TStreamSocket or TDatagramSocket) and write your own DoXNotification() functions to override the default behavior. For example, the TStreamSocket::DoWriteNotification() function tries to write any data that is in its outgoing queue. You could, for example, make a subclass called TPOPSocket() that sends and receives POP notifications and commands upon DoReadNotification() and DoWriteNotification() calls.
If you set TSocket to do external notifications, it will redirect FD_XXX notifications to the window of your choice. You can tell TSocket to redirect any combination of notifications to the given window by OR-ing the appropriate values together. Only the notifications that you OR together will get redirected to the window; the others go to the DoXNotification() functions, as usual. You may want to redirect all notifications to a window so that you can respond to each of the notifications when they come. You could, for example, redirect only FD_ACCEPT messages to a window so that all listening sockets send FD_ACCEPT messages to the same window. You call the SetNotificationWindow function to set the window for the notifications to be set. These windows are set on a TSocket by TSocket basis, and you only have to set it once for a given TSocket. When you call SetNotificationSet() you tell the it what notifications to redirect. There is an enumeration set (nNotifyWrite) that duplicates the FD set (FD_WRITE). You can use either set, as they are effectively equal.
Identifiers and functions for external notification:
1.10.0