青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

大龍的博客

常用鏈接

統(tǒng)計

最新評論

MSG_PARTIAL 選項解釋(畫----的那部分)

Connectionless Communication
Connectionless communication behaves differently than connection-oriented communication, so the method for sending and receiving data is substantially different. First we'll discuss the receiver (or server, if you prefer) because the connectionless 
receiver requires little change when compared with the connection-oriented servers. After that we'll look at the sender.

In IP, connectionless communication is accomplished through UDP/IP. UDP doesn't guarantee reliable data transmission and is capable of sending data to multiple destinations and receiving it from multiple sources. For example, if a client sends data to 
a server, the data is transmitted immediately regardless of whether the server is ready to receive it. If the server receives data from the client, it doesn't acknowledge the receipt. Data is transmitted using datagrams, which are discrete message 
packets.

Receiver
The steps in the process of receiving data on a connectionless socket are simple. First, create the socket with either socket or WSASocket. Next, bind the socket to the interface on which you wish to receive data. This is done with the bind function 
(exactly like the session-oriented example). The difference with connectionless sockets is that you do not call listen or accept. Instead, you simply wait to receive the incoming data. Because there is no connection, the receiving socket can receive 
datagrams originating from any machine on the network. The simplest of the receive functions is recvfrom, which is defined as

int recvfrom(
    SOCKET s,
    char FAR* buf,
    int len,
    int flags,
    struct sockaddr FAR* from,
    int FAR* fromlen
);
The first four parameters are the same as recv, including the possible values for flags: MSG_OOB and MSG_PEEK. The same warnings for using the MSG_PEEK flag also apply to connectionless sockets. The from parameter is a SOCKADDR structure for the given 
protocol of the listening socket, with fromlen pointing to the size of the address structure. When the API call returns with data, the SOCKADDR structure is filled with the address of the workstation that sent the data.

The Winsock 2 version of the recvfrom function is WSARecvFrom. The prototype for this function is

int WSARecvFrom(
    SOCKET s,
    LPWSABUF lpBuffers,
    DWORD dwBufferCount,
    LPDWORD lpNumberOfBytesRecvd,
    LPDWORD lpFlags,
    struct sockaddr FAR * lpFrom,
    LPINT lpFromlen,
    LPWSAOVERLAPPED lpOverlapped,
    LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine
);
The difference is the use of WSABUF structures for receiving the data. You can supply one or more WSABUF buffers to WSARecvFrom with dwBufferCount indicating this. By supplying multiple buffers, scatter-gather I/O is possible. The total number of bytes 
read is returned in lpNumberOfBytesRecvd. When you call WSARecvFrom, the lpFlags parameter can be 0 for no options, MSG_OOB, MSG_PEEK, or MSG_PARTIAL. These flags can be bitwise OR together. If MSG_PARTIAL is specified when the function is called, the 
provider knows to return data even if only a partial message has been received. Upon return, the flag MSG_PARTIAL is set if only a partial message was received. Upon return, WSARecvFrom will store the address of the sending machine in the lpFrom 
parameter (a pointer to a SOCKADDR structure). Again, lpFromLen points to the size of the SOCKADDR structure, except that in this function it is a pointer to a DWORD. The last two parameters, lpOverlapped and lpCompletionRoutine, are used for 
overlapped I/O (which we'll discuss in Chapter 5).

Another method of receiving (and sending) data on a connectionless socket is to establish a connection. This might seem strange, but it's not quite what it sounds like. Once a connectionless socket is created, you can call connect or WSAConnect with 
the SOCKADDR parameter set to the address of the remote machine to communicate with. No actual connection is made, however. The socket address passed into a connect function is associated with the socket so recv and WSARecv can be used instead of 
recvfrom or WSARecvFrom because the data's origin is known. The capability to connect a datagram socket is handy if you intend to communicate with only one endpoint at a time in your application.

The following code sample demonstrates how to construct a simple UDP receiver application. You will find a complete version of this application in a file named UDPRECEIVER on the companion CD.

#include <winsock2.h>

void main(void)
{
   WSADATA              wsaData;
   SOCKET               ReceivingSocket;
   SOCKADDR_IN          ReceiverAddr;
   int                  Port = 5150;
   char                 ReceiveBuf[1024];
   int                  BufLength = 1024;
   SOCKADDR_IN          SenderAddr;
   int                  SenderAddrSize = sizeof(SenderAddr);
   
   // Initialize Winsock version 2.2

   WSAStartup(MAKEWORD(2,2), &wsaData);
   
      // Create a new socket to receive datagrams on.
 
      ReceivingSocket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);

      // Set up a SOCKADDR_IN structure that will tell bind that we
      // want to receive datagrams from all interfaces using port
      // 5150.

      ReceiverAddr.sin_family = AF_INET;
      ReceiverAddr.sin_port = htons(Port);    
      ReceiverAddr.sin_addr.s_addr = htonl(INADDR_ANY);

      // Associate the address information with the socket using bind.

      bind(ReceivingSocket, (SOCKADDR *)&SenderAddr, sizeof(SenderAddr));

   // At this point you can receive datagrams on your bound socket.
   recvfrom(ReceivingSocket, ReceiveBuf, BufLength, 0,
            (SOCKADDR *)&SenderAddr, &SenderAddrSize);

   // When your application is finished receiving datagrams close
   // the socket.

   closesocket(ReceivingSocket);

   // When your application is finished call WSACleanup.

   WSACleanup();
}
Now that you understand how to construct a receiver that can receive a datagram, we will describe how to construct a sender.

Sender
There are two options to send data on a connectionless socket. The first, and simplest, is to create a socket and call either sendto or WSASendTo. We'll cover sendto first, which is defined as

int sendto(
    SOCKET s,
    const char FAR * buf,
    int len,
    int flags,
    const struct sockaddr FAR * to,
    int tolen
);
The parameters are the same as recvfrom except that buf is the buffer of data to send and len indicates how many bytes to send. Also, the to parameter is a pointer to a SOCKADDR structure with the destination address of the workstation to receive the 
data. The Winsock 2 function WSASendTo can also be used. This function is defined as

int WSASendTo(
    SOCKET s,                                               
    LPWSABUF lpBuffers,                                     
    DWORD dwBufferCount,                                    
    LPDWORD lpNumberOfBytesSent,                            
    DWORD dwFlags,                                          
    const struct sockaddr FAR * lpTo,                       
    int iToLen,                                             
    LPWSAOVERLAPPED lpOverlapped,                           
    LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine
);
Again, WSASendTo is similar to its ancestor. This function takes a pointer to one or more WSABUF structures with data to send to the recipient as the lpBuffers parameter, with dwBufferCount indicating how many structures are present. You can send 
multiple WSABUF structures to enable scatter-gather I/O. Before returning, WSASendTo sets the fourth parameter, lpNumberOfBytesSent, to the number of bytes actually sent to the receiver. The lpTo parameter is a SOCKADDR structure for the given 
protocol, with the recipient's address. The iToLen parameter is the length of the SOCKADDR structure. The last two parameters, lpOverlapped and lpCompletionRoutine, are used for overlapped I/O (discussed in Chapter 5).

As with receiving data, a connectionless socket can be connected to an endpoint address and data can be sent with send and WSASend. Once this association is established, you cannot go back to using sendto or WSASendTo with an address other than the 
address passed to one of the connect functions. If you attempt to send data to a different address, the call will fail with WSAEISCONN. The only way to disassociate the socket handle from that destination is to call connect with the destination address 
of INADDR_ANY.

The following code sample demonstrates how to construct a simple UDP sender application. You will find a complete version of this application on the companion CD in a file named UDPSENDER.

#include <winsock2.h>

void main(void)
{
   WSADATA              wsaData;
   SOCKET               SendingSocket;
   SOCKADDR_IN          ReceiverAddr;
   int                  Port = 5150;
   char                 SendBuf[1024];
   int                  BufLength = 1024;

   // Initialize Winsock version 2.2

   WSAStartup(MAKEWORD(2,2), &wsaData);
   
   // Create a new socket to receive datagrams on.
 
   SendingSocket = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
   
   // Set up a SOCKADDR_IN structure that will identify who we
   // will send datagrams to. For demonstration purposes, let's
   // assume our receiver's IP address is 136.149.3.29 and waits
   // for datagrams on port 5150.

   ReceiverAddr.sin_family = AF_INET;
   ReceiverAddr.sin_port = htons(Port);    
   ReceiverAddr.sin_addr.s_addr = inet_addr("136.149.3.29");

   // Send a datagram to the receiver.

   sendto(SendingSocket, SendBuf, BufLength, 0, 
          (SOCKADDR *)&ReceiverAddr, sizeof(RecieverAddr));
          
   // When your application is finished sending datagrams close
   // the socket.

   closesocket(SendingSocket);

   // When your application is finished call WSACleanup.

   WSACleanup();
}
Message-Based Protocols
Just as most connection-oriented communication is also streaming, connectionless communication is almost always message-based. Thus, there are some considerations when you're sending and receiving data. First, because message-based protocols preserve 
data boundaries, data submitted to a send function blocks until completed. For non-blocking I/O modes, if a send cannot be completely satisfied, the send function returns with the error WSAEWOULDBLOCK. This means that the underlying system was not able 
to process that data and you should attempt the send call again at a later time. This scenario will be discussed in greater detail in Chapter 5. The main point to remember is that with message-based protocols, the write can occur as an autonomous 
action only.

---------------------------------------
On the flip side, a call to a receive function must supply a sufficiently large buffer. If the supplied buffer is not large enough, the receive call fails with the error WSAEMSGSIZE. If this occurs, the buffer is filled to its capacity, but the 
remaining data is discarded. The truncated data cannot be retrieved. The only exception is for protocols that do support partial messages, such as the AppleTalk PAP protocol. Prior to returning, the WSARecv, WSARecvEx, or WSARecvFrom functions set the 
in-out flag parameter to MSG_PARTIAL when it receives only part of a message.
---------------------------------------


For datagrams based on protocols supporting partial messages, consider using one of the WSARecv* functions because when you make a call to recv/recvfrom, there is no notification that the data read is only a partial message. It is up to the programmer 
to implement a method for the receiver to determine if the entire message has been read. Subsequent calls to recv/recvfrom return other pieces of the datagram. Because of this limitation, it can be convenient to use the WSARecvEx function, which allows 
the setting and reading of the MSG_PARTIAL flag to indicate if the entire message was read. The Winsock 2 functions WSARecv and WSARecvFrom also support this flag. See the descriptions for WSARecv, WSARecvEx, and WSARecvFrom for additional information 
about this flag.

Finally, let's take a look at one of the more frequently asked questions about sending UDP/IP messages on machines with multiple network interfaces: What happens when a UDP socket is bound explicitly to a local IP interface and datagrams are sent? With 
UDP sockets, you don't really bind to the network interface; you create an association whereby the IP interface that is bound becomes the source IP address of UDP datagrams sent. The routing table actually determines which physical interface the 
datagram is transmitted on. If you do not call bind but instead use either sendto/WSASendTo or perform a connect first, the network stack automatically picks the best local IP address based on the routing table. So if you explicitly bind first, the 
source IP address could be incorrect. That is, the source IP might not be the IP address of the interface on which the datagram was actually sent.

Releasing Socket Resources
Because there is no connection with connectionless protocols, there is no formal shutdown or graceful closing of the connection. When the sender or the receiver is finished sending or receiving data, it simply calls the closesocket function on the 
socket handle. This releases any associated resources allocated to the socket.

posted on 2008-05-07 09:45 大龍 閱讀(1639) 評論(1)  編輯 收藏 引用

評論

# re: MSG_PARTIAL 選項解釋(畫----的那部分) 2011-08-30 14:57 QVOD

很有幫助!  回復(fù)  更多評論   


只有注冊用戶登錄后才能發(fā)表評論。
網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            国产精品a久久久久| 亚洲精品视频免费观看| 亚洲欧美日韩精品久久久| 国产精品一区视频| 久久精品成人一区二区三区| 亚洲欧美日韩国产综合| 亚洲黄色大片| 在线一区二区三区四区| 国产精品久久久久久久久久尿| 午夜精品成人在线视频| 欧美一区二区在线播放| 亚洲国产一区在线观看| 亚洲乱码日产精品bd| 国产视频一区三区| 亚洲成人中文| 国产精品永久在线| 免费日本视频一区| 欧美日韩在线视频一区二区| 午夜视频一区在线观看| 久久色在线观看| 亚洲在线观看免费| 久久久久久久高潮| 亚洲网在线观看| 久久精品国产免费| 亚洲综合国产激情另类一区| 久久综合九色综合欧美狠狠| av成人免费在线| 久久精品国产亚洲a| 一区二区三区回区在观看免费视频| 亚洲欧美一区二区激情| 亚洲精品综合| 久久精品一区二区三区不卡牛牛| av成人毛片| 美女尤物久久精品| 久久国产88| 欧美视频日韩视频在线观看| 蜜臀av在线播放一区二区三区| 欧美日一区二区在线观看| 蜜桃av一区| 国产伦精品一区二区| 亚洲精品视频在线看| 亚洲二区在线| 久久电影一区| 久久久999精品| 国产精品视频免费在线观看| 亚洲精品欧美激情| 亚洲欧洲精品一区二区精品久久久| 在线亚洲免费| 亚洲深夜福利| 欧美日韩1区| 亚洲精品美女在线观看| 亚洲国产精品久久久久| 久久人人九九| 欧美激情一区二区在线| 精品91在线| 久久国产黑丝| 久久久亚洲国产美女国产盗摄| 国产精品午夜在线| 亚洲综合99| 欧美综合国产精品久久丁香| 国产精品激情av在线播放| av成人免费在线| 亚洲一区二区三区免费视频| 欧美日韩精品免费在线观看视频| 亚洲高清色综合| 亚洲美女视频在线观看| 欧美日韩八区| 国产精品99久久久久久久vr| 亚洲欧美高清| 国产亚洲成av人在线观看导航| 亚洲欧美另类在线观看| 久久久之久亚州精品露出| 激情五月婷婷综合| 久久99伊人| 欧美日韩在线视频一区二区| 一本久久综合亚洲鲁鲁五月天| 宅男噜噜噜66一区二区| 欧美午夜寂寞影院| 亚久久调教视频| 免费日韩精品中文字幕视频在线| 久久国产天堂福利天堂| 久久精品官网| 国产精品一区二区三区免费观看| 亚洲视频www| 久久精品国产v日韩v亚洲| 国产在线不卡精品| 麻豆9191精品国产| 亚洲另类视频| 久久国产精品一区二区三区四区 | 性欧美video另类hd性玩具| 久久精品一本| 亚洲精品美女| 国产精品一二三四区| 久久久精品国产免大香伊| 亚洲国产精品va| 午夜久久久久久久久久一区二区| 国内精品久久久久久影视8| 欧美成人精品在线播放| 亚洲资源av| 亚洲国产电影| 久久国产精品网站| 亚洲人成毛片在线播放| 国产精品日韩精品欧美在线| 久久综合激情| 香蕉成人久久| 日韩亚洲在线| 免费在线亚洲| 久久成人免费电影| 一区二区免费在线播放| 今天的高清视频免费播放成人| 欧美视频在线观看| 美女日韩欧美| 欧美在线一级视频| 99精品视频一区二区三区| 久久综合九色欧美综合狠狠| 亚洲伊人久久综合| 亚洲精品护士| 亚洲高清在线观看| 国产一区三区三区| 国产精品久久午夜| 欧美日本三级| 欧美大片免费久久精品三p| 久久久国产精品一区二区三区| 亚洲视频999| 一区二区三区四区五区在线| 亚洲国产二区| 亚洲国产91| 欧美成人免费va影院高清| 久久久夜色精品亚洲| 久久久久久久久蜜桃| 亚洲欧美日韩一区二区三区在线观看| 99国内精品久久| 亚洲七七久久综合桃花剧情介绍| 狠狠色2019综合网| 精品成人免费| 韩国精品主播一区二区在线观看| 国产精品免费一区二区三区观看| 欧美日韩免费观看一区二区三区| 免费观看在线综合色| 另类av一区二区| 暖暖成人免费视频| 欧美成人国产一区二区| 麻豆av福利av久久av| 欧美一区国产在线| 亚洲国产网站| 国产裸体写真av一区二区| 国产精品福利av| 欧美午夜不卡影院在线观看完整版免费| 免费不卡在线观看| 免费h精品视频在线播放| 欧美成人午夜免费视在线看片| 免费一级欧美在线大片| 免费中文日韩| 欧美区高清在线| 欧美视频第二页| 国产欧美精品日韩| 伊人天天综合| 日韩一级精品视频在线观看| 99在线热播精品免费| 亚洲自拍偷拍视频| 欧美自拍丝袜亚洲| 欧美大片免费观看| 亚洲美女啪啪| 欧美在线免费观看| 牛人盗摄一区二区三区视频| 欧美人与禽性xxxxx杂性| 国产精品久久九九| 狠狠久久五月精品中文字幕| 亚洲欧洲视频| 亚洲淫性视频| 老司机精品久久| 日韩视频一区二区在线观看| 性做久久久久久免费观看欧美| 久久久噜噜噜久久久| 欧美人与性动交a欧美精品| 国产欧美日韩伦理| 亚洲精品乱码久久久久久| 亚洲欧美日韩天堂一区二区| 欧美成年人视频网站| 亚洲调教视频在线观看| 久久免费的精品国产v∧| 欧美日韩亚洲一区二区三区在线| 国产综合第一页| 宅男精品导航| 欧美激情第二页| 亚洲免费在线观看视频| 欧美成人一区二区| 黄色av成人| 亚洲免费视频观看| 亚洲第一区在线| 欧美中在线观看| 国产精品久久久久久妇女6080 | 午夜宅男欧美| 久久久精彩视频| 欧美成人精品1314www| 亚洲一区二区日本| 欧美激情国产高清| 精品99一区二区| 午夜精品亚洲| 亚洲美女91|