异步套接字问题，执行步骤。。。再线

Question

while(true)
{
socket.beginreceive(...);
}
回调函数是RECVCALLBACK。
beginreceive后，程序会不会立刻开始下一次while循环啊，又一个beginreceive？这样会不会资源占完死机？
如果beginreceive后，而远端没发数据就关闭了，这样会如何？

Answer 1

你的回调函数中应该有endreceive()方法，并且要向系统投递下一个接收请求，所以你说的情况是不存在的，下面是一个完整的回调函数：　
private void ReceiveCallBack(IAsyncResult ar)
        ...{
            UserInfo info = (UserInfo)ar.AsyncState;
            Socket handler = info.socket;
            int readCount = 0;
            try
            ...{
                readCount = handler.EndReceive(ar);//调用这个函数来结束本次接收并返回接收到的数据长度。
            }
            catch (SocketException)//出现Socket异常就关闭连接
            ...{
                CloseSocket(info);//这个函数用来关闭客户端连接
                return;
            }
            catch
            ...{
            }
            if (readCount > 0)
            ...{
                byte[] buffer = new byte[readCount];
                Buffer.BlockCopy(info.Buffer, 0, buffer, 0, readCount);
                Analyzer(info, buffer);//这个函数用来处理接收到的信息。
                try
                ...{
                    handler.BeginReceive(info.Buffer, 0, info.Buffer.Length, SocketFlags.None, new AsyncCallback(ReceiveCallBack), info);//向系统投递下一个接收请求
                }
                catch (SocketException) //出现Socket异常就关闭连接
                ...{
                    CloseSocket(info);
                }
                catch
                ...{
                }
            }
            else //如果接收到0字节的数据说明客户端关闭了Socket，那我们也要关闭Socket
            ...{
                CloseSocket(info);
            }
        }

Answer 2

while(true) 
{ 
socket.beginreceive(...); 
} 这种做法是错误的，这里只要执行一次BeginReceive就行了，以后的BeginReceive应该在EndReceive里面执行。
所以，把while循环去掉！

Answer 3

socket异步方面性能反而比同步垃圾很多倍,不管你是
while(true)   
{   
socket.beginreceive(...);   
} 还是楼上说的以后的BeginReceive应该在EndReceive里面执行。依然垃圾得不得了,因为这种SOCKET异步会不停的开关线程来做,自己测试一下就知道了.建议楼主采用同步方式接收,发送方面可以采用异步发送. 

Answer 4

听他们说用同步，压力过大时，会导致不能全部接收（多连接，多记录），是不是啊？
所以业务大时要用异步，请wzd24和wzd24给我讲解下啊？嫌分少了说下，我加点啊

Answer 5

错，是“请wzd24和wo_deaizainali给我讲解下啊？”

Answer 6

你要承受多大的连接???如果你真的要承受上万连接的话,那首选就不应该是采用.NET来做.
.NET的SOCKET异步的开销不小,我自己实验得来的结果是很多不管连接少还是连接多,异步的性能
都要落后于同步性能,因为比如楼上的，<这里只要执行一次BeginReceive就行了，以后的BeginReceive应该在EndReceive里面执行。 >比如一条连接建立,那么异步情况下接收,就会不停的开更多线程来完成接收工作.性能很是垃圾,不要以为异步所用的线程池线程经过什么优化,异步的开启关闭线程依然是很开销资源的.如果很多连接话就更
垃圾得简直不能用,相反,我们来对比同步,一条连接只会用一个线程进行管理,开销要小得多.

Answer 7

我因为调试时弄不清运做流程，用ManualResetEvent（RECVDONE）来限定，比如：我beginreceive后，RECVDONE.waitone();等endreceive完了再RECVDONE.set();
这样是不是就相当与同步了？？？？

Answer 8

反对wo_deaizainali所说的异步性能低于同步的说法，异步并非不停的创建和销毁线程。而是系统内核事先已经创建了数个线程用来执行异步代码，所以其性能会比同步高出很多，但使用异步时必须要注意线程同步问题及其所造成的性能损耗，很多人就是因为在异步中使用ManualResetEvent而导致异步的效率甚至比同步还低。

Answer 9

wzd24早就看过你BLOG了,你能拿一个实在的列子出来证明.NET的SOCKET异步性能高于同步吗?
你BLOG讲的东西没有什么意义,MSDN都讲得有很清楚,你拿一个实际的列子出来证明,比如传送文件,语音视频传送等列子来说明你说的.NET异步性能高于同步,那我就相信你的说法.

Answer 10

MSDN讲了同步性能比异步性能高？？不解。什么是线程池？线程池就是预先创建数个线程。然后在需要时取出其中的空闲线程来处理事务。如果线程池也是不停的创建和销毁线程来处理事务的话，那还要线程池干什么？

Answer 11

别光说嘴皮子,我上面就说了,你拿个实际的DEMO来证明.NET SOCKET异步性能高于同步是最好的证明,你拿一个实际的列子出来证明,比如传送文件,语音视频传送等列子来说明你说的.NET SOCKET异步性能高于同步,那我就相信你的说法.