亚洲午夜精品久久,欧美在线视频全部完,香蕉久久一区二区不卡无毒影院

解析IP

warrior — Thu, 14 Aug 2008 09:52:00 GMT

1 //析取IP地址�Q�如果说是合法的IP则返回true,否则�q�回 false
2 bool GetProxyIP( std::wstring& strIP )
3 {
4     strIP.clear();
5     LPCWSTR pszIP = GetEditBoxText( IDC_DLG_LOGIN_SETTING_EDIT_ADDRESS );
6     if( pszIP == NULL || !wcscmp( pszIP, TEXT("") ) )
7         return false;
8
9     std::wstring strTemp = pszIP;
10     std::wstring::size_type nPos1, nPos2;
11     nPos1 = nPos2 = 0;
12     int nIP[4] = {0};
13     std::wstring::size_type i = 0;
14     for( ; (i < 4) && (nPos2 != std::wstring::npos ); ++i )
15     {
16         if( nPos2 == 0 )
17             nPos1 = nPos2;
18         else
19             nPos1 = nPos2 + 1;
20
21         nPos2 = strTemp.find( TEXT('.'), nPos1);
22         std::wstring::size_type nCount = std::wstring::npos;
23         if( nPos2 != std::wstring::npos )
24             nCount = nPos2 - nPos1;
25
26         std::wstring strSub = strTemp.substr(nPos1, nCount);
27         if( strSub == TEXT("") )
28             return false;
29
30         int nValue = _wtoi( strSub.c_str() );
31         if( nValue < 0 || nValue > 255 )
32             return false;
33         nIP[i] = nValue;
34     }
35
36     if( i < 4 )
37         return false;
38     wchar_t szIP[100] = {0};
39     wsprintf( szIP, TEXT("%d.%d.%d.%d"), nIP[0], nIP[1], nIP[2], nIP[3] );
40     strIP = szIP;
41     return true;
42 }

warrior 2008-08-14 17:52 发表评论

[转]URL�~�码

warrior — Thu, 04 Jan 2007 05:46:00 GMT

URL�~�码
作者：(x��) Chandrasekhar Vuppalapati
��译�Q�eastvc

下蝲源代�?/a>

本文的目的是设计一个完成URL�~�码的C++�c�R��在我曾�l�的��目中，我需要从VC++ 6.0应用�E�序中POST数据�Q�而这些数据需要进行URL�~�码。我在MSDN中查找能�Ҏ(gu��)��提供的字�W�串生成URL�~�码的相关类或API�Q�但我没有找刎ͼ�因此我必��设计一个自��q��URLEncode C++�c�R�?/p>

URLEncoder.exe是一个��用URLEncode�cȝ��MFC对话框程序�?/p>

如何处理

一些特�D�字�W�在Internet上传送是件棘手的事情, �l�URL�~�码�Ҏ(gu��)��处理�Q�可以��所有字�W�安全地从Internet传送�?/p>

例如�Q�回车的ASCII值是13�Q�在发送FORM数据时候这��p��为是一行数据的�l�束�?/p>

通常�Q�所有应用程序采用HTTP或HTTPS协议在客��L(f��ng)��和服务器端传送数据。服务器端从客户端接收数据有两种基本�Ҏ(gu��)��Q?/p>

1、数据可以从HTTP头传送（COOKIES或作为FORM数据发送）
2、可以包含在URL中的查询部分

当数据包含在URL�Q�它必须遵��@URL语法�q�行�~�码。在WEB服务器端�Q�数据自动解码。考虑一下下面的URL�Q�哪个数据是作�ؓ(f��)查询参数�?/p>

例如�Q�http://WebSite/ResourceName?Data=Data

WebSite是URL名称
ResourceName可以是ASP或Servlet名称
Data是需要发送的数据。如果MIME�c�d��是Content-Type: application/x-www-form-urlencoded�Q�则要求�q�行�~�码�?/p>

RFC 1738

RFC 1738指明了统一资源定位(URLs)中的字符应该是US-ASCII字符集的子集。这是受HTML的限�Ӟ��另一斚w��Q�允许在文档中��用所有ISO- 8859-1(ISO-Latin)字符集。这��意味着在HTML FORM里POST的数据（或作为查询字串的一部分�Q�，所有HTML�~�码必须被编码�?/p>

ISO-8859-1 (ISO-Latin)字符�?/p>

在下表中�Q�包含了完整的ISO-8859-1 (ISO-Latin)字符集，表格提供了每个字�W�范��_(d��)��10�q�制�Q�，描述�Q�实际��|��十六�q�制��|��HTML�l�果。某个范围中的字�W�是否安全�?br />

Character range(decimal)	Type	Values	Safe/Unsafe
0-31	ASCII Control Characters	These characters are not printable	Unsafe
32-47	Reserved Characters	'' ''!?#$%&''()*+,-./	Unsafe
48-57	ASCII Characters and Numbers	0-9	Safe
58-64	Reserved Characters	:;<=>?@	Unsafe
65-90	ASCII Characters	A-Z	Safe
91-96	Reserved Characters	[\]^_`	Unsafe
97-122	ASCII Characters	a-z	Safe
123-126	Reserved Characters	{\|}~	Unsafe
127	Control Characters	'' ''	Unsafe
128-255	Non-ASCII Characters	'' ''	Unsafe

所有不安全的ASCII字符都需要编码，例如�Q�范�?32-47, 58-64, 91-96, 123-126)�?br />下表描述了这些字�W��ؓ(f��)什么不安全�?

Character	Unsafe Reason	Character Encode
"<"	Delimiters around URLs in free text	%3C
>	Delimiters around URLs in free text	%3E
.	Delimits URLs in some systems	%22
#	It is used in the World Wide Web and in other systems to delimit a URL from a fragment/anchor identifier that might follow it.	%23
{	Gateways and other transport agents are known to sometimes modify such characters	%7B
}	Gateways and other transport agents are known to sometimes modify such characters	%7D
\|	Gateways and other transport agents are known to sometimes modify such characters	%7C
\	Gateways and other transport agents are known to sometimes modify such characters	%5C
^	Gateways and other transport agents are known to sometimes modify such characters	%5E
~	Gateways and other transport agents are known to sometimes modify such characters	%7E
[	Gateways and other transport agents are known to sometimes modify such characters	%5B
]	Gateways and other transport agents are known to sometimes modify such characters	%5D
`	Gateways and other transport agents are known to sometimes modify such characters	%60
+	Indicates a space (spaces cannot be used in a URL)	%20
/	Separates directories and subdirectories	%2F
?	Separates the actual URL and the parameters	%3F
&	Separator between parameters specified in the URL	%26

如何实现

字符的URL�~�码是将字符转换�?�?6�q�制�q�在前面加上''%''前缀。例如，US-ASCII字符集中�I�格�?0�q�制
�?2�?6�q�制�?0�Q�因此，URL�~�码�?20�?/p>

URLEncode: URLEncode是一个C++�c�，来实现字�W�串的URL�~�码。CURLEncode�c�d��含如下函敎ͼ�(x��)
isUnsafeString
decToHex
convert
URLEncode

URLEncode()函数完成�~�码�q�程�Q�URLEncode��查每个字�W�，看是否安全。如果不安全��用%16�q�制��D��行�{换�ƈ��d��
到原始字�W�串中�?/p>

代码片断 :

class CURLEncode
{
private:
  static CString csUnsafeString;
  CString (char num, int radix);
  bool isUnsafe(char compareChar);
  CString convert(char val);

public:
  CURLEncode() { };
  virtual ~CURLEncode() { };
  CString (CString vData);
};

bool CURLEncode::isUnsafe(char compareChar)
{
  bool bcharfound = false;
  char tmpsafeChar;
  int m_strLen = 0;

  m_strLen = csUnsafeString.GetLength();
  for(int ichar_pos = 0; ichar_pos < m_strLen ;ichar_pos++)
  {
    tmpsafeChar = csUnsafeString.GetAt(ichar_pos);
    if(tmpsafeChar == compareChar)
    {
      bcharfound = true;
      break;
    }
  }
  int char_ascii_value = 0;
  //char_ascii_value = __toascii(compareChar);
  char_ascii_value = (int) compareChar;

  if(bcharfound == false &&  char_ascii_value > 32 &&
                             char_ascii_value < 123)
  {
    return false;
  }
  // found no unsafe chars, return false
  else
  {
    return true;
  }

  return true;
}

CString CURLEncode::decToHex(char num, int radix)
{
  int temp=0;
  CString csTmp;
  int num_char;

num_char = (int) num;
  if (num_char < 0)
    num_char = 256 + num_char;

  while (num_char >= radix)
    {
    temp = num_char % radix;
    num_char = (int)floor(num_char / radix);
    csTmp = hexVals[temp];
    }

  csTmp += hexVals[num_char];

  if(csTmp.GetLength() < 2)
  {
    csTmp += ''0'';
  }

  CString strdecToHex(csTmp);
  // Reverse the String
  strdecToHex.MakeReverse();

  return strdecToHex;
}

CString CURLEncode::convert(char val)
{
  CString csRet;
  csRet += "%";
  csRet += decToHex(val, 16);
  return  csRet;
}

参考：(x��)

URL�~�码: http://www.blooberry.com/indexdot/html/topics/urlencoding.htm.

RFC 1866: The HTML 2.0 规范 (�U�文�?. 附录包含了字�W�表: http://www.rfc-editor.org/rfc/rfc1866.txt.

Web HTML 2.0 版本(RFC 1866) : http://www.w3.org/MarkUp/html-spec/html-spec_13.html.

The HTML 3.2 (Wilbur) ��: http://www.w3.org/MarkUp/Wilbur/.

The HTML 4.0 ��: http://www.w3.org/TR/REC-html40/.

W3C HTML 国际化区�? http://www.w3.org/International/O-HTML.html.

warrior 2007-01-04 13:46 发表评论

[转]用完成端口开发大响应规模的Winsock应用�E�序

warrior — Thu, 04 Jan 2007 05:42:00 GMT

用完成端口开发大响应规模的Winsock应用�E�序

原文出处�Q?a target="_blank">http://msdn.microsoft.com/msdnmag/issues/1000/Winsock/

通常要开发网�l�应用程序�ƈ不是一件轻杄��事情�Q�不�q�，实际上只要掌握几个关键的原则也就可以了——创建和�q�接一个套接字�Q�尝试进行连接，然后收发数据。真正难的是要写��Z��个可以接�U�_��则一个，多则数千个连接的�|�络应用�E�序。本文将讨论如何通过Winsock2在Windows NT �?Windows 2000上开发高扩展能力的Winsock应用�E�序。文章主要的焦点在客��h��/服务器模型的服务器这一方，当然�Q�其中的许多要点�Ҏ(gu��)��型的双方都适用�?

API与响应规�?/strong>

通过Win32的重叠I/O机制�Q�应用程序可以提请一��I/O操作�Q�重叠的操作��h��在后台完成，而同一旉��提请操作的线�E�去做其他的事情。等重叠操作完成后线�E�收到有关的通知。这�U�机制对那些耗时的操作而言特别有用。不�q�，像Windows 3.1上的WSAAsyncSelect()�?qi��ng)Unix下的select()那样的函数虽然易于��用，但是它们不能满��响应规模的需要。而完成端口机制是针对操作�pȝ��内部�q�行了优化，在Windows NT �?Windows 2000上，使用了完成端口的重叠I/O机制才能够真正扩大系�l�的响应规模�?/p>
完成端口

一个完成端口其实就是一个通知队列�Q�由操作�pȝ��把已�l�完成的重叠I/O��h��的通知攑օ�其中。当某项I/O操作一旦完成，某个可以对该操作�l�果�q�行处理的工作者线�E�就�?x��)收��C��则通知。而套接字在被创徏后，可以在�Q何时候与某个完成端口�q�行兌��?/p>
通常情况下，我们�?x��)在应用�E�序中创��Z��定数量的工作者线�E�来处理�q�些通知。线�E�数量取决于应用�E�序的特定需要。理想的情况是，�U�程数量�{�于处理器的数量�Q�不�q�这也要求�Q何线�E�都不应该执行诸如同步读写、等待事仉��知�{�阻塞型的操作，以免�U�程��d��。每个线�E�都��分��C��定的CPU旉��Q�在此期间该�U�程可以�q�行�Q�然后另一个线�E�将分到一个时间片�q�开始执行。如果某个线�E�执行了��d��型的操作�Q�操作系�l�将剥夺其未使用的剩余时间片�q�让其它�U�程开始执行。也��是��_(d��)��前一个线�E�没有充分��用其旉��片，当发生这��L(f��ng)��情况�Ӟ��应用�E�序应该准备其它�U�程来充分利用这些时间片�?/p>
完成端口的��用分��Z��步。首先创建完成端口，如以下代码所�C�：(x��)

HANDLE hIocp; hIocp = CreateIoCompletionPort( INVALID_HANDLE_VALUE, NULL, (ULONG_PTR)0, 0); if (hIocp == NULL) { // Error }
完成端口创徏后，要把��用该完成端口的套接字与之兌��h��。方法是再次调用CreateIoCompletionPort ()函数�Q�第一个参数FileHandle设�ؓ(f��)套接字的句柄�Q�第二个参数ExistingCompletionPort 设�ؓ(f��)刚刚创徏的那个完成端口的句柄�?br />以下代码创徏了一个套接字�Q��ƈ把它和前面创建的完成端口兌��h��Q?
SOCKET s; s = socket(AF_INET, SOCK_STREAM, 0); if (s == INVALID_SOCKET) { // Error if (CreateIoCompletionPort((HANDLE)s, hIocp, (ULONG_PTR)0, 0) == NULL) { // Error } ... }

�q�时��完成了套接字与完成端口的关联操作。在�q�个套接字上�q�行的�Q何重叠操作都��通过完成端口发出完成通知。注意，CreateIoCompletionPort()函数中的�W�三个参数用来设�|�一个与该套接字相关的“完成键(completion key)�?译者注�Q�完成键可以是�Q何数据类�?。每当完成通知到来�Ӟ��应用�E�序可以��d��相应的完成键�Q�因此，完成键可用来�l�套接字传递一些背景信息�?
在创��Z��完成端口、将一个或多个套接字与之相兌��之后�Q�我们就要创��q�个�U�程来处理完成通知。这些线�E�不断��@环调用GetQueuedCompletionStatus ()函数�q�返回完成通知�?/p>
下面�Q�我们先来看看应用程序如何跟�t�这些重叠操作。当应用�E�序调用一个重叠操作函数时�Q�要把指向一个overlapped�l�构的指针包括在其参��C��。当操作完成后，我们可以通过GetQueuedCompletionStatus()函数中拿回这个指针。不�q�，单是�Ҏ(gu��)��q�个指针所指向的overlapped �l�构�Q�应用程序�ƈ不能分��L�I�竟完成的是哪个操作。要实现�Ҏ(gu��)��作的跟踪�Q�你可以自己定义一个OVERLAPPED�l�构�Q�在其中加入所需的跟�t�信息�?/p>
无论何时调用重叠操作函数�Ӟ��L��?x��)通过其lpOverlapped参数传递一个OVERLAPPEDPLUS�l�构(例如WSASend�?WSARecv�{�函�?。这��允�怽�为每一个重叠调用操作设�|�某些操作状态信息，当操作结束后�Q�你可以通过 GetQueuedCompletionStatus()函数获得你自定义�l�构的指针。注意OVERLAPPED字段不要求一定是�q�个扩展后的�l�构的第一个字�D�c(di��n)��当得到了指向OVERLAPPED�l�构的指针以后，可以用CONTAINING_RECORD宏取出其中指向扩展结构的指针�?/p>
OVERLAPPED �l�构的定义如下：(x��)
typedef struct _OVERLAPPEDPLUS { OVERLAPPED ol; SOCKET s, sclient; int OpCode; WSABUF wbuf; DWORD dwBytes, dwFlags; // 其它有用的信�? } OVERLAPPEDPLUS; #define OP_READ 0 #define OP_WRITE 1 #define OP_ACCEPT 2
下面让我们来看看工作者线�E�的情况�?br />
工作�U�程WorkerThread代码�Q?
DWORD WINAPI WorkerThread(LPVOID lpParam) { ULONG_PTR *PerHandleKey; OVERLAPPED *Overlap; OVERLAPPEDPLUS *OverlapPlus, *newolp; DWORD dwBytesXfered; while (1) { ret = GetQueuedCompletionStatus( hIocp, &dwBytesXfered, (PULONG_PTR)&PerHandleKey, &Overlap, INFINITE); if (ret == 0) { // Operation failed continue; } OverlapPlus = CONTAINING_RECORD(Overlap, OVERLAPPEDPLUS, ol); switch (OverlapPlus->OpCode) { case OP_ACCEPT: // Client socket is contained in OverlapPlus.sclient // Add client to completion port CreateIoCompletionPort( (HANDLE)OverlapPlus->sclient, hIocp, (ULONG_PTR)0, 0); // Need a new OVERLAPPEDPLUS structure // for the newly accepted socket. Perhaps // keep a look aside list of free structures. newolp = AllocateOverlappedPlus(); if (!newolp) { // Error } newolp->s = OverlapPlus->sclient; newolp->OpCode = OP_READ; // This function prepares the data to be sent PrepareSendBuffer(&newolp->wbuf); ret = WSASend( newolp->s, &newolp->wbuf, 1, &newolp->dwBytes, 0, &newolp.ol, NULL); if (ret == SOCKET_ERROR) { if (WSAGetLastError() != WSA_IO_PENDING) { // Error } } // Put structure in look aside list for later use FreeOverlappedPlus(OverlapPlus); // Signal accept thread to issue another AcceptEx SetEvent(hAcceptThread); break; case OP_READ: // Process the data read // ... // Repost the read if necessary, reusing the same // receive buffer as before memset(&OverlapPlus->ol, 0, sizeof(OVERLAPPED)); ret = WSARecv( OverlapPlus->s, &OverlapPlus->wbuf, 1, &OverlapPlus->dwBytes, &OverlapPlus->dwFlags, &OverlapPlus->ol, NULL); if (ret == SOCKET_ERROR) { if (WSAGetLastError() != WSA_IO_PENDING) { // Error } } break; case OP_WRITE: // Process the data sent, etc. break; } // switch } // while } // WorkerThread
其中每句柄键(PerHandleKey)变量的内容，是在把完成端口与套接字进行关联时所讄��的完成键参数�Q�Overlap参数�q�回的是一个指向发出重叠操作时所使用的那个OVERLAPPEDPLUS�l�构的指针�?
要记住，如果重叠操作调用��p�|�?也就是说�Q�返回值是SOCKET_ERROR�Q��ƈ且错误原因不是WSA_IO_PENDING)�Q�那么完成端口将不会(x��)收到��M��完成通知。如果重叠操作调用成功，或者发生原因是WSA_IO_PENDING的错误时�Q�完成端口将��L��能够收到完成通知�?br />
Windows NT和W(xu��)indows 2000的套接字架构

对于开发大响应规模的Winsock应用�E�序而言�Q�对Windows NT和W(xu��)indows 2000的套接字架构有基本的了解是很有帮助的。下图是Windows 2000中的Winsock架构�Q?br />
与其它类型操作系�l�不同，W(xu��)indows NT和W(xu��)indows 2000的传输协议没有一�U�风格像套接字那��L(f��ng)��、可以和应用�E�序直接交谈的界面，而是采用了一�U�更为底层的API�Q�叫做传输驱动程序界�?Transport Driver Interface,TDI)。Winsock的核心模式驱动程序负责连接和�~�冲区管理，以便向应用程序提供套接字仿真(在AFD.SYS文�g中实�?�Q�同时负责与底层传输驱动�E�序对话�?/p>
谁来负责��理�~�冲区？

正如上面所说的�Q�应用程序通过Winsock来和传输协议驱动�E�序交谈�Q�而AFD.SYS负责为应用程序进行缓冲区��理。也��是��_(d��)��当应用程序调�?send()或WSASend()函数来发送数据时�Q�AFD.SYS��把数据拯��q�它自己的内部缓冲区(取决于SO_SNDBUF讑֮��?�Q�然后send ()或WSASend()函数立即�q�回。也可以�q�么��_(d��)��AFD.SYS在后台负责把数据发送出厅R��不�q�，如果应用�E�序要求发出的数据超�q�了 SO_SNDBUF讑֮�的缓冲区大小�Q�那么WSASend()函数�?x��)阻塞，直至所有数据发送完毕�?/p>
从远�E�客��L(f��ng)��接收数据的情况也�c�M��。只要不用从应用�E�序那里接收大量的数据，而且没有��出SO_RCVBUF讑֮�的��|��AFD.SYS��把数据先拷贝到其内部缓冲区中。当应用�E�序调用recv()或WSARecv()函数�Ӟ��数据��从内部�~�冲拯��到应用程序提供的�~�冲区�?/p>
多数情况下，�q�样的架构运行良好，特别在是应用�E�序采用传统的套接字下非重叠的send()和receive()模式�~�写的时候。不�q�程序员要小心的是，��管可以通过setsockopt()�q�个API来把SO_SNDBUF和SO_RCVBUF选项��D��?(关闭内部�~�冲�?�Q�但是程序员必须十分清楚�?AFD.SYS的内部缓冲区��x��?x��)造成什么后果，避免收发数据时有关的�~�冲区拷贝可能引��L(f��ng)��pȝ��崩溃�?/p>
举例来说�Q�一个应用程序通过讑֮�SO_SNDBUF�?把缓冲区关闭�Q�然后发��Z��个阻塞send()调用。在�q�样的情况下�Q�系�l�内�怼�(x��)把应用程序的�~�冲区锁定，直到接收方确认收��C��整个�~�冲区后send()调用才返回。似乎这是一�U�判定你的数据是否已�l��ؓ(f��)�Ҏ(gu��)��全部收到的简�z�的�Ҏ(gu��)��Q�实际上却�ƈ非如此。想想看�Q�即使远端TCP 通知数据已经收到�Q�其实也�Ҏ(gu��)��不代表数据已�l�成功送给客户端应用程序，比如�Ҏ(gu��)��可能发生资源不��的情况，��D��AFD.SYS不能把数据拷贝给应用�E�序。另一个更要紧的问题是�Q�在每个�U�程中每�ơ只能进行一�ơ发送调用，效率极其低下�?/p>
把SO_RCVBUF设�ؓ(f��)0�Q�关闭AFD.SYS的接收缓冲区也不能让性能得到提升�Q�这只会(x��)�q��接收到的数据在比Winsock更低的层�ơ进行缓�Ԍ��当你发出receive调用�Ӟ��同样要进行缓冲区拯��Q�因此你本来想避免缓冲区拯��的阴谋不�?x��)得逞�?/p>
现在我们应该清楚了，关闭�~�冲区对于多数应用程序而言�q�不是什么好��L��。只要要应用�E�序注意随时在某个连接上保持几个WSARecvs重叠调用�Q�那么通常没有必要关闭接收�~�冲区。如果AFD.SYS��L��有由应用�E�序提供的缓冲区可用�Q�那么它?y��u)��没有必要��用内部缓冲区�?/p>
高性能的服务器应用�E�序可以关闭发送缓冲区�Q�同时不�?x��)损失性能。不�q�，�q�样的应用程序必��d��分小心，保证它��L��发出多个重叠发送调用，而不是等待某个重叠发送结束了才发��Z��一个。如果应用程序是按一个发完再发下一个的��序来操作，那浪�Ҏ(gu��)��两次发送中间的�I�档旉��Q��M��是要保证传输驱动�E�序在发送完一个缓冲区后，立刻可以转向另一个缓冲区�?/p>
资源的限制条�?/strong>
在设计�Q何服务器应用�E�序�Ӟ��其强健性是主要的目标。也��是��_(d��)��
你的应用�E�序要能够应对�Q何突发的问题�Q�例如�ƈ发客戯��求数辑ֈ�峰倹{��可用内存��(f��)时出��C��뀁以�?qi��ng)其它短旉��的现象。这��p��求程序的设计者注意Windows NT�?000�pȝ��下的资源限制条�g的问题，从容地处理突发性事件�?/p>
你可以直接控制的、最基本的资源就是网�l�带宽。通常�Q��用用��h��据报协议(UDP)的应用程序都可能�?x��)比较注意带宽方面的限制�Q�以最大限度地减少包的丢失。然而，在��用TCP�q�接�Ӟ��服务器必��d��分小心地控制好，防止�|�络带宽�q�蝲��过一定的旉��Q�否则将需要重发大量的包或造成大量�q�接中断。关于带宽管理的�Ҏ(gu��)��应根据不同的应用�E�序而定�Q�这��出了本文讨论的范围�?/p>
虚拟内存的��用也必须很小心地��理。通过谨慎地申请和释放内存�Q�或者应用lookaside lists(一�U�高速缓�?技术来重新使用已分配的内存�Q�将有助于控制服务器应用�E�序的内存开销(原文为“让服务器应用程序留下的脚印��一点�?�Q�避免操作系�l�频�J�地��应用程序申��L(f��ng)��物理内存交换到虚拟内存中(原文为“让操作�pȝ��能够��L��把更多的应用�E�序地址�I�间更多��C��留在内存中�?。你也可以通过 SetWorkingSetSize()�q�个Win32 API让操作系�l�分配给你的应用�E�序更多的物理内存�?/p>
在��用Winsock时还可能��到另外两个非直接的资源不��情况。一个是被锁定的内存��面的极限。如果你把AFD.SYS的缓冲关闭，当应用程序收发数据时�Q�应用程序缓冲区的所有页面将被锁定到物理内存中。这是因为内栔R��动程序需要访问这些内存，在此期间�q�些��面不能交换出去。如果操作系�l�需要给其它应用�E�序分配一些可分页的物理内存，而又没有��_��的内存时��׃��(x��)发生问题。我们的目标是要防止写出一个病态的、锁定所有物理内存、让�pȝ��崩溃的程序。也��是��_(d��)��你的�E�序锁定内存�Ӟ��不要��出�pȝ��规定的内存分��|��限�?/p>
在Windows NT�?000�pȝ��上，所有应用程序��d��可以锁定的内存大�U�是物理内存�?/8(不过�q�只是一个大概的估计�Q�不是你计算内存的依�?。如果你的应用程序不注意�q�一点，当你的发出太多的重叠收发调用�Q�而且I/O没来得及(qi��ng)完成�Ӟ��可能偶��?d��ng)发生ERROR_INSUFFICIENT_RESOURCES的错误。在�q�种情况下你要避免过度锁定内存。同时要注意�Q�系�l�会(x��)锁定包含你的�~�冲区所在的整个内存��面�Q�因此缓冲区靠近��边界时是有代�h(hu��n)�?译者理解，�~�冲区如果正好超�q�页面边界，那怕是1个字节，��出的这个字节所在的��面也会(x��)被锁�?�?/p>
另外一个限制是你的�E�序可能�?x��)遇到系�l�未分页池资源不��的情况。所谓未分页池是一块永�q�不被交换出�ȝ��内存区域�Q�这块内存用来存储一些供各种内核�l��g讉K��的数据，其中有的内核�l��g是不能访问那些被交换出去的页面空间的。Windows NT�?000的驱动程序能够从�q�个特定的未分页池分配内存�?/p>
当应用程序创��Z��个套接字(或者是�c�M��的打开某个文�g)�Ӟ��内核�?x��)从未分��|��中分配一定数量的内存�Q�而且在绑定、连接套接字�Ӟ��内核又会(x��)从未分页池中再分配一些内存。当你注意观察这�U�行为时你将发现�Q�如果你发出某些I/O��h��?例如收发数据)�Q�你�?x��)从未分��|��里再分配多一些内�?比如要追�t�某个待决的 I/O操作�Q�你可能需要给�q�个操作��d��一个自定义�l�构�Q�如前文所提及(qi��ng)�?。最后这��可能会(x��)造成一定的问题�Q�操作系�l�会(x��)限制未分��内存的用量�?/p>
在Windows NT�?000�q�两�U�操作系�l�上�Q�给每个�q�接分配的未分页内存的具体数量是不同的，未来版本的Windows很可能也不同。�ؓ(f��)了��应用�E�序的生命期更长�Q�你��׃��应该计算�Ҏ(gu��)��分页池内存的具体需求量�?/p>
你的�E�序必须防止消耗到未分��|��的极限。当�pȝ��中未分页池剩余空间太��时�Q�某些与你的应用�E�序毫无关系的内栔R��动就�?x��)发疯，甚至造成�pȝ��崩溃�Q�特别是当系�l�中有第三方讑֤�或驱动程序时�Q�更�Ҏ(gu��)��发生�q�样的惨�?而且无法预测)。同时你�q�要��C��Q�同一台电(sh��)脑上�q�可能运行有其它同样消耗未分页池的其它应用�E�序�Q�因此在设计你的应用�E�序�Ӟ��对资源量的预估要特别保守和�}慎�?/p>
处理资源不��的问题是十分复杂的，因�ؓ(f��)发生上述情况时你不会(x��)收到特别的错误代码，通常你只能收��C��般性的WSAENOBUFS或者ERROR_INSUFFICIENT_RESOURCES 错误。要处理�q�些错误�Q�首先，把你的应用程序工作配�|�调整到合理的最大�?译者注�Q�所谓工作配�|�，是指应用�E�序各部分运行中所需的内存用量，请参�?http://msdn.microsoft.com/msdnmag/issues/1000/Bugslayer/Bugslayer1000.asp �Q�关于内存优化，译者另有译�?�Q�如果错误��l�出玎ͼ�那么注意��查是否是�|�络带宽不��的问题。之后，��L(f��ng)��认你没有同时发出太多的收发调用。最后，如果�q�是收到资源不��的错误，那就很可能是遇到了未分页内存池不��的问题了。要释放未分��内存池�I�间�Q�请关闭应用�E�序中相当部分的�q�接�Q�等待系�l�自行渡�q�和修正�q�个瞬时的错误�?br />
接受�q�接��h��

服务器要做的最普通的事情之一��是接受来自客户端的�q�接��h��。在套接字上使用重叠I/O接受�q�接的惟一API��是AcceptEx()函数。有��的是，通常的同步接受函数accept()的返回值是一个新的套接字�Q�而AcceptEx()函数则需要另外一个套接字作�ؓ(f��)它的参数之一。这是因�?AcceptEx()是一个重叠操作，所以你需要事先创��Z��个套接字(但不要绑定或�q�接�?�Q��ƈ把这个套接字通过参数传给AcceptEx()。以下是一��段典型的��用AcceptEx()的伪代码�Q?
do { -�{�待上一�?AcceptEx 完成 -创徏一个新套接字�ƈ与完成端口进行关�? -讄��背景�l�构�{�等 -发出一�?AcceptEx ��h�� }while(TRUE);
作�ؓ(f��)一个高响应能力的服务器�Q�它必须发出��_��的AcceptEx调用�Q�守候着�Q�一旦出现客��L(f��ng)��q�接��h��q��d��应。至于发出多��个AcceptEx才够�Q�就取决于你的服务器�E�序所期待的通信交通类型。比如，如果�q�入�q�接率高的情�?因�ؓ(f��)�q�接持箋旉��较短�Q�或者出��C��通高�?�Q�那么所需要守候的 AcceptEx当然要比那些偶尔�q�入的客��L(f��ng)��q�接的情况要多。聪明的做法是，由应用程序来分析交通状况，�q�调整AcceptEx守候的数量�Q�而不是固定在某个数量上�?
对于Windows2000�Q�W(xu��)insock提供了一些机�Ӟ��帮助你判定AcceptEx的数量是否��够。这��是�Q�在创徏监听套接字时创徏一个事�Ӟ��通过WSAEventSelect()�q�个API�q�注册FD_ACCEPT事�g通知来把套接字和�q�个事�g兌��h��。一旦系�l�收��C��个连接请求，如果�pȝ��中没有AcceptEx()正在�{�待接受�q�接�Q�那么上面的事�g��收��C��个信受��通过�q�个事�g�Q�你��可以判断你有没有发��够的 AcceptEx()�Q�或者检��出一个非正常的客戯��?下文�q?。这�U�机制对Windows NT 4.0不适用�?/p>
使用AcceptEx()的一大好处是�Q�你可以通过一�ơ调用就完成接受客户端连接请求和接受数据(通过传送lpOutputBuffer参数)两�g事情。也��是��_(d��)��如果客户端在发出�q�接的同时传输数据，你的AcceptEx()调用在连接创建�ƈ接收了客��L(f��ng)��数据后就可以立刻�q�回。这样可能是很有用的�Q�但是也可能�?x��)引发问题，因��?f��)AcceptEx()必须�{�全部客��L(f��ng)��数据都收��C��才返回。具体来��_(d��)��如果你在发出AcceptEx()调用的同时传递了lpOutputBuffer参数�Q�那么AcceptEx()不再是一��原子型的操作，而是分成了两步：(x��)接受客户�q�接�Q�等待接收数据。当�~�少一�U�机制来通知你的应用�E�序所发生的这�U�情况：(x��)“连接已�l�徏立了�Q�正在等待客��L(f��ng)��数据”，�q�将意味着有可能出现客��L(f��ng)��只发��接请求，但是不发送数据。如果你的服务器收到太多�q�种�c�d��的连接时�Q�它?y��u)��拒�l�连接更多的合法客户端请求。这��是黑客�q�行“拒�l�服务”攻�ȝ��常见手法�?/p>
要预防此�c�L��击，接受�q�接的线�E�应该不时地通过调用getsockopt()函数(选项参数�?SO_CONNECT_TIME)来检查AcceptEx()里守候的套接字。getsockopt()函数的选项值将被设�|��ؓ(f��)套接字被�q�接的时��_(d��)��或者设�|��ؓ(f��)-1(代表套接字尚未徏立连�?。这�Ӟ��W(xu��)SAEventSelect()的特性就可以很好地利用来做这�U�检查。如果发现连接已�l�徏立，但是很久都没有收到数据的情况�Q�那么就应该�l�止�q�接�Q�方法就是关闭作为参数提供给AcceptEx()的那个套接字。注意，在多数非紧急情况下�Q�如果套接字已经传递给AcceptEx()�q�开始守候，但还未徏立连接，那么你的应用�E�序不应该关闭它们。这是因为即使关闭了�q�些套接字，��Z��提高�pȝ��性能的考虑�Q�在�q�接�q�入之前�Q�或者监听套接字自��n被关闭之前，相应的内核模式的数据�l�构也不�?x��)被�q�净地清除�?/p>
发出AcceptEx()调用的线�E�，��g��与那个进行完成端口关联操作、处理其它I/O完成通知的线�E�是同一个，但是�Q�别忘记�U�程里应该尽力避免执行阻塞型的操作。Winsock2分层�l�构的一个副作用是调用socket()或WSASocket() API的上层架构可能很重要(译者不太明白原文意思，抱歉)。每个AcceptEx()调用都需要创��Z��个新套接字，所以最好有一个独立的�U�程专门调用AcceptEx()�Q�而不参与其它I/O处理。你也可以利用这个线�E�来执行其它��d��Q�比如事件记录�?/p>
有关AcceptEx()的最后一个注意事��：(x��)要实现这些API�Q��ƈ不需要其它提供商提供的Winsock2实现。这一点对微��Y�Ҏ(gu��)��的其它API也同样适用�Q�比如TransmitFile()和GetAcceptExSockAddrs()�Q�以�?qi��ng)其它可能�?x��)被加入到新版Windows的API. 在Windows NT�?000上，�q�些API是在微��Y的底层提供者DLL(mswsock.dll)中实现的�Q�可通过与mswsock.lib�~�译�q�接�q�行调用�Q�或者通过WSAIoctl() (选项参数为SIO_GET_EXTENSION_FUNCTION_POINTER)动态获得函数的指针�?/p>
如果在没有事先获得函数指针的情况下直接调用函�?也就是说�Q�编译时静态连接mswsock.lib�Q�在�E�序中直接调用函�?�Q�那么性能��很受媄响。因�?AcceptEx()被置于Winsock2架构之外�Q�每�ơ调用时它都被迫通过WSAIoctl()取得函数指针。要避免�q�种性能损失�Q�需要��用这�?API的应用程序应该通过调用WSAIoctl()直接从底层的提供者那里取得函数的指针�?br />
参见下图套接字架构：(x��)

TransmitFile �?TransmitPackets

Winsock 提供两个专门为文件和内存数据传输�q�行了优化的函数。其中TransmitFile()�q�个API函数在Windows NT 4.0 �?Windows 2000上都可以使用�Q�而TransmitPackets()则将在未来版本的Windows中实现�?/p>
TransmitFile ()用来把文件内定w��过Winsock�q�行传输。通常发送文件的做法是，先调用CreateFile()打开一个文�Ӟ��然后不断循环调用ReadFile () 和W(xu��)SASend ()直至数据发送完毕。但是这�U�方法很没有效率�Q�因为每�ơ调用ReadFile() �?WSASend ()都会(x��)涉及(qi��ng)一�ơ从用户模式到内核模式的转换。如果换成TransmitFile()�Q�那么只需要给它一个已打开文�g的句柄和要发送的字节敎ͼ�而所涉及(qi��ng)的模式�{换操作将只在调用CreateFile()打开文�g时发生一�ơ，然后TransmitFile()时再发生一�ơ。这��h��率就高多了�?/p>
TransmitPackets()比TransmitFile()更进一步，它允许用户只调用一�ơ就可以发送指定的多个文�g和内存缓冲区。函数原型如下：(x��)
BOOL TransmitPackets( SOCKET hSocket, LPTRANSMIT_PACKET_ELEMENT lpPacketArray, DWORD nElementCount, DWORD nSendSize, LPOVERLAPPED lpOverlapped, DWORD dwFlags );
其中�Q�lpPacketArray是一个结构的数组�Q�其中的每个元素既可以是一个文件句柄或者内存缓冲区�Q�该�l�构定义如下�Q?br />
typedef struct _TRANSMIT_PACKETS_ELEMENT { DWORD dwElFlags; DWORD cLength; union { struct { LARGE_INTEGER nFileOffset; HANDLE hFile; }; PVOID pBuffer; }; } TRANSMIT_FILE_BUFFERS;
其中各字�D�|��自描�q�型�?self explanatory)�?br />dwElFlags字段�Q�指定当前元素是一个文件句柄还是内存缓冲区(分别通过帔R��TF_ELEMENT_FILE 和TF_ELEMENT_MEMORY指定)�Q?br />cLength字段�Q�指定将从数据源发送的字节�?如果是文�Ӟ��q�个字段��gؓ(f��)0表示发送整个文�?�Q?br />�l�构中的无名联合体：(x��)包含文�g句柄的内存缓冲区(以及(qi��ng)可能的偏�U�量)�?
使用�q�两个API的另一个好处，是可以通过指定TF_REUSE_SOCKET和TF_DISCONNECT标志来重用套接字句柄。每当API完成数据的传输工作后�Q�就�?x��)在传输层��别断开�q�接�Q�这栯��个套接字��又可以重新提供�l�AcceptEx()使用。采用这�U�优化的�Ҏ(gu��)��~�程�Q�将减轻那个专门做接受操作的�U�程创徏套接字的压力(前文�q�及(qi��ng))�?/p>
�q�两个API也都有一个共同的��q��Q�Windows NT Workstation �?Windows 2000 专业版中�Q�函数每�ơ只能处理两个调用请求，只有在Windows NT、Windows 2000服务器版、Windows 2000高��服务器版�?Windows 2000 Data Center中才获得完全支持�?/p>
攑֜�一��L(f��ng)��?/strong>
以上各节中，我们讨论了开发高性能的、大响应规模的应用程序所需的函数、方法和可能遇到的资源瓶颈问题。这些对你意味着什么呢�Q�其实，�q�取决于你如何构造你的服务器和客��L(f��ng)��。当你能够在服务器和客户端设计上�q�行更好地控制时�Q�那么你��能够避开瓉��问题�?/p>
来看一个示范的环境。我们要设计一个服务器来响应客��L(f��ng)��的连接、发送请求、接收数据以�?qi��ng)断开�q�接。那么，服务器将需要创��Z��个监听套接字�Q�把它与某个完成端口�q�行兌��Q��ؓ(f��)每颗CPU创徏一个工作线�E�。再创徏一个线�E�专门用来发出AcceptEx()。我们知道客��L(f��ng)��?x��)在发出�q�接��h��后立��M��送数据，所以如果我们准备好接收�~�冲��Z��(x��)使事情变得更为容易。当�Ӟ��不要忘记不时地轮询AcceptEx()调用中��用的套接�?使用SO_CONNECT_TIME选项参数)来确保没有恶意超时的�q�接�?/p>
该设计中有一个重要的问题要考虑�Q�我们应该允许多��个AcceptEx()�q�行守候。这是因为，每发��Z��个AcceptEx()时我们都同时需要�ؓ(f��)它提供一个接收缓冲区�Q�那么内存中��会(x��)出现很多被锁定的��面(前文说过了，每个重叠操作都会(x��)消耗一��部分未分页内存池，同时�q�会(x��)锁定所有涉�?qi��ng)的�~�冲�?。这个问题很隑֛��{�，没有一个确切的�{�案。最好的�Ҏ(gu��)��是把�q�个值做成可以调整的�Q�通过反复做性能��试�Q�你��可以得出在典型应用环境中最佳的倹{�?/p>
好了�Q�当你测��清楚后�Q�下面就是发送数据的问题了，考虑的重�Ҏ(gu��)��你希望服务器同时处理多少个�ƈ发的�q�接。通常情况下，服务器应该限制�ƈ发连接的数量以及(qi��ng)�{�候处理的发送调用。因为�ƈ发连接数量越多，所消耗的未分��内存池也越多；�{�候处理的发送调用越多，被锁定的内存��面也越�?��心别超�q�了极限)。这同样也需要反复测试才知道�{�案�?/p>
对于上述环境�Q�通常不需要关闭单个套接字的缓冲区�Q�因为只在AcceptEx()中有一�ơ接收数据的操作�Q�而要保证�l�每个到来的�q�接提供接收�~�冲区�ƈ不是太难的事情。但是，如果客户��Z��服务器交互的方式变一变，客户机在发送了一�ơ数据之后，�q�需要发送更多的数据�Q�在�q�种情况下关闭接收缓冲就不太妙了�Q�除非你惛_��法保证在每个�q�接上都发出了重叠接收调用来接收更多的数据�?/p>
�l�论
开发大响应规模的Winsock服务器�ƈ不是很可怕，其实也就是设�|�一个监听套接字、接受连接请求和�q�行重叠收发调用。通过讄��合理的进行守候的重叠调用的数量，防止出现未分��内存池被耗尽�Q�这才是最主要的挑战。按照我们前面讨论的一些原则，你就可以开发出大响应规模的服务器应用程序�?/p>

warrior 2007-01-04 13:42 发表评论

warrior — Mon, 11 Dec 2006 08:39:00 GMT

#include
#include

#define TCP

#pragma comment(lib,"ws2_32.lib")

int main( int argc ,char* argv[])
{
WSAData wsaData;

WSAStartup(WINSOCK_VERSION,&wsaData);
DWORD begin,finish;

struct timeval tv;
tv.tv_sec = 5000;
tv.tv_usec = 0;
int optlen = sizeof(struct timeval);

//
SOCKET sock = socket(PF_INET,SOCK_STREAM,0);

struct sockaddr_in to;
int len = sizeof(struct sockaddr_in);
memset(&to,0,len);

to.sin_addr.s_addr = inet_addr("202.108.9.39");;
to.sin_port = htons(80);
to.sin_family = AF_INET;

if ( connect(sock,(struct sockaddr*)&to,len) == SOCKET_ERROR )
{
  closesocket(sock);
  return 0;
}

//讄��时��gؓ(f��)tv
if ( setsockopt(sock,SOL_SOCKET,SO_RCVTIMEO,(char*)&tv,optlen) ==
  SOCKET_ERROR)
{
  closesocket(sock);
  return 0;
}

char buf[100];
if ( recv(sock,buf,100,0) == SOCKET_ERROR )
{
  printf("d");
}

return 0;
}

warrior 2006-12-11 16:39 发表评论

使用MFC提供的Http�c�M��载和上传文�g

warrior — Thu, 28 Sep 2006 03:34:00 GMT

1、下载文�?br />Download(const CString& strFileURLInServer, //待下载文件的URL
const CString & strFileLocalFullPath)//存放到本地的路径
{
ASSERT(strFileURLInServer != "");
ASSERT(strFileLocalFullPath != "");
CInternetSession session;
CHttpConnection* pHttpConnection = NULL;
CHttpFile* pHttpFile = NULL;
CString strServer, strObject;
INTERNET_PORT wPort;

DWORD dwType;
const int nTimeOut = 2000;
session.SetOption(INTERNET_OPTION_CONNECT_TIMEOUT, nTimeOut); //重试之间的等待�g�?br /> session.SetOption(INTERNET_OPTION_CONNECT_RETRIES, 1);   //重试�ơ数
char* pszBuffer = NULL;

try
{
  AfxParseURL(strFileURLInServer, dwType, strServer, strObject, wPort);
  pHttpConnection = session.GetHttpConnection(strServer, wPort);
  pHttpFile = pHttpConnection->OpenRequest(CHttpConnection::HTTP_VERB_GET, strObject);
  if(pHttpFile->SendRequest() == FALSE)
   return false;
  DWORD dwStateCode;

  pHttpFile->QueryInfoStatusCode(dwStateCode);
  if(dwStateCode == HTTP_STATUS_OK)
  {
    HANDLE hFile = CreateFile(strFileLocalFullPath, GENERIC_WRITE,
         FILE_SHARE_WRITE, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL,
         NULL);  //创徏本地文�g
   if(hFile == INVALID_HANDLE_VALUE)
   {
    pHttpFile->Close();
    pHttpConnection->Close();
    session.Close();
    return false;
   }

   char szInfoBuffer[1000];  //�q�回消息
   DWORD dwFileSize = 0;   //文�g长度
   DWORD dwInfoBufferSize = sizeof(szInfoBuffer);
   BOOL bResult = FALSE;
   bResult = pHttpFile->QueryInfo(HTTP_QUERY_CONTENT_LENGTH,
           (void*)szInfoBuffer,&dwInfoBufferSize,NULL);

   dwFileSize = atoi(szInfoBuffer);
   const int BUFFER_LENGTH = 1024 * 10;
   pszBuffer = new char[BUFFER_LENGTH];  //��d��文�g的缓�?br />   DWORD dwWrite, dwTotalWrite;
   dwWrite = dwTotalWrite = 0;
   UINT nRead = pHttpFile->Read(pszBuffer, BUFFER_LENGTH); //��d��服务器上数据

   while(nRead > 0)
   {
    WriteFile(hFile, pszBuffer, nRead, &dwWrite, NULL);  //写到本地文�g
    dwTotalWrite += dwWrite;
    nRead = pHttpFile->Read(pszBuffer, BUFFER_LENGTH);
   }

   delete[]pszBuffer;
   pszBuffer = NULL;
   CloseHandle(hFile);
  }
  else
  {
   delete[]pszBuffer;
   pszBuffer = NULL;
   if(pHttpFile != NULL)
   {
    pHttpFile->Close();
    delete pHttpFile;
    pHttpFile = NULL;
   }
   if(pHttpConnection != NULL)
   {
    pHttpConnection->Close();
    delete pHttpConnection;
    pHttpConnection = NULL;
   }
   session.Close();
    return false;
  }
}
catch(...)
{
  delete[]pszBuffer;
  pszBuffer = NULL;
  if(pHttpFile != NULL)
  {
   pHttpFile->Close();
   delete pHttpFile;
   pHttpFile = NULL;
  }
  if(pHttpConnection != NULL)
  {
   pHttpConnection->Close();
   delete pHttpConnection;
   pHttpConnection = NULL;
  }
  session.Close();
  return false;
}

if(pHttpFile != NULL)
  pHttpFile->Close();
if(pHttpConnection != NULL)
  pHttpConnection->Close();
session.Close();
return true;
}

2、上传文�?br />UploadFile(LPCTSTR strURL, //负责接收上传操作的页面的URL
LPCTSTR strLocalFileName) //待上传的本地文�g路径
{
ASSERT(strURL != NULL && strLocalFileName != NULL);

BOOL bResult = FALSE;
DWORD dwType = 0;
CString strServer;
CString strObject;
INTERNET_PORT wPort = 0;
DWORD dwFileLength = 0;
char * pFileBuff = NULL;

CHttpConnection * pHC = NULL;
CHttpFile * pHF = NULL;
CInternetSession cis;

bResult = AfxParseURL(strURL, dwType, strServer, strObject, wPort);
if(!bResult)
  return FALSE;
CFile file;
try
{
  if(!file.Open(strLocalFileName, CFile::shareDenyNone | CFile::modeRead))
   return FALSE;
  dwFileLength = file.GetLength();
  if(dwFileLength <= 0)
   return FALSE;
  pFileBuff = new char[dwFileLength];
  memset(pFileBuff, 0, sizeof(char) * dwFileLength);
  file.Read(pFileBuff, dwFileLength);

  const int nTimeOut = 5000;
  cis.SetOption(INTERNET_OPTION_CONNECT_TIMEOUT, nTimeOut); //联接��时讄��
  cis.SetOption(INTERNET_OPTION_CONNECT_RETRIES, 1);  //重试1��?br />  pHC = cis.GetHttpConnection(strServer, wPort);  //取得一个Http联接

  pHF = pHC->OpenRequest(CHttpConnection::HTTP_VERB_POST, strObject);
  if(!pHF->SendRequest(NULL, 0, pFileBuff, dwFileLength))
  {
   delete[]pFileBuff;
   pFileBuff = NULL;
   pHF->Close();
   pHC->Close();
   cis.Close();
   return FALSE;
  }
  DWORD dwStateCode = 0;
  pHF->QueryInfoStatusCode(dwStateCode);

  if(dwStateCode == HTTP_STATUS_OK)
   bResult = TRUE;
}

catch(CInternetException * pEx)
{
  char sz[256] = "";
  pEx->GetErrorMessage(sz, 25);
  CString str;
  str.Format("InternetException occur!\r\n%s", sz);
  AfxMessageBox(str);
}
catch(CFileException& fe)
{
  CString str;
  str.Format("FileException occur!\r\n%d", fe.m_lOsError);
  AfxMessageBox(str);
}
catch(...)
{
  DWORD dwError = GetLastError();
  CString str;
  str.Format("Unknow Exception occur!\r\n%d", dwError);
  AfxMessageBox(str);
}

delete[]pFileBuff;
pFileBuff = NULL;
file.Close();
pHF->Close();
pHC->Close();
cis.Close();
return bResult;
}

warrior 2006-09-28 11:34 发表评论