-Windows CE network programming memorandum (original)

 

1. The wsaasyncselect function is not supported in Windows ce5.0. After this function is called, the socket (possibly socket transliteration) is automatically set to non-blocking mode, register one or more events of interest (fd_close...) with Winsock DLL ...), it also provides a window handle used for notification. When a registered network event occurs, the corresponding window will receive a message-based notification and you can write the processing code.

The alternative function can use select or wsaeventselect. The biggest difference between wsaeventselect and wsaasyncselect is that network events are sent to an event object handle rather than to a window.

This wsaeventselect requires the Winsock version 2.0: Requirements

Version:Requires Windows Sockets 1.1 or later.
Header:Declared in winsock2.h.
Library:Use ws2_32.lib.

2 The select function can be used in blocking and non-blocking Io. That is to say, after the select function is called, the socket is not automatically set to non-blocking mode. In fact, there is nothing to do with the mode, if it is in blocking mode, it will not be blocked in the Recv function, but blocked in the select function. However, the Select function has a timeout exit mechanism and uses timeval to determine the waiting event, after exiting, you can do other things. After you finish the job, you can continue to block the SELECT statement. Use a while (1.

3 In network functions, the buffer related to sending and receiving data belongs to the simple char type. That is to say, these functions do not have a "Unicode" version, when using Unicode, you need to treat the string you want to send as char * or simply convert it into char *. Send: When the string length function is used to tell the winsock API function how many characters the data is sent and received, multiply by 2 because each character occupies two bytes of the string array. In addition, you can use WideCharToMultiByte to convert UNICODE to ASCii code before assigning string data to the Winsock API. I use the latter in my windowCE program. The advantage is that the amount of data transmitted over the network is reduced by 1/2.

Since the Uncode version of the winsock function is not available, when _ T ("192.168.0.10") is passed to the connect function, it can be compiled but cannot be connected, it took a lot of effort to search for this error.

4. Let's take a look at the description of the WSAEnumNetworkEvents function Excerpted from MSDN:

The socket's internal record of network events is copied to the structure referencedLpNetworkEvents, After which the internal network events record is cleared. IfHEventObjectParameter is not NULL, the indicated event object is also reset. the Windows Sockets provider guarantees that the operations of copying the network event record, clearing it and resetting any associated event object are automatic, such that the next occurrence of a nominated network event will cause the event object to become set. in the case of this function returning SOCKET_ERROR, the associated event object is not reset and the record of network events is not cleared.

The last sentence is worth noting.

5 if (networkEvents. lNetworkEvents & FD_CLOSE)
{
If (0! = NetworkEvents. iErrorCode [FD_CLOSE_BIT])
{
: PostMessage (HWND) lpParameter, WM_SERVER_MESSAGE, 0, 2 );
}
Else
{
: Postmessage (hwnd) lpparameter, wm_server_message, 0, 1 );
Getpeername (g_socks [index-wsa_wait_event_0], (sockaddr *) & name, & namelen );
// Closesocket (g_socks [index-wsa_wait_event_0]); // when this sentence is added, it will enter an endless loop.
}

}

I don't know why closesocket is always a problem. If this sentence is added, fd_close cannot be cleared or is repeatedly sent by the system (I don't know what the situation is, but I prefer the latter) this causes an endless loop.

6 While (1)
{
If (true = g_bquit)
Break;

Index = wsawaitformultipleevents (g_numofevents, g_events ,/
False, wsa_infinite/* timeout_usecs */, false );
Trace (_ T ("index: % d/tg_numofevents: % d/N"), index, g_numofevents );

If TIMEOUT_USECS is used, an infinite number of FD_ACCEPT values are generated, leading to an endless loop. I don't know what's going on.

7 int res = recv (g_Socks [index-WSA_WAIT_EVENT_0], pbuf, BUF_SIZE, 0 );
If (res> 0)
{
Pbuf + = res;
If (TCPIP_DATA_LENGTH = pbuf-buf) // The major defect here is that if the received data exceeds TCPIP_DATA_LENGTH once or cumulatively (not exactly reached TCPIP_DATA_LENGTH), it will never be displayed.
{
Buf [TCPIP_DATA_LENGTH] = '/0 ';

G_csNet.Lock ();

Memcpy (g_buf, buf, sizeof (buf ));

Write by xiaoxiongli is not complete...