200分!!关于C++网络通信编程。
关于C++网络通信方面的例子:我有以下几个问题不是很明白?第一,假设我做了一个网络通信的客户端,和服务端,现在各种初始化工作已经做好,现在服务端已经启动服务,现在客户端向...
关于C++网络通信方面的例子:
我有以下几个问题不是很明白?
第一,假设我做了一个网络通信的客户端,和服务端,现在各种初始化工作已经做好,现在服务端已经启动服务,现在客户端向服务端发送请求连接,问题来了,怎样在服务端的某个静态控件域显示客户端的连
请求信息,比如,客户端一调用Connect函数,服务端某个静态控件上显示“XX客户请求连接",然后服务端点击”接受连接“控件后,这个静态控件上又显示”你已经接受XX 的请求连接",然后会话。问题是服务端怎样
知道客户端什么时候调用了Connect的连接请求函数,从而在静态控件上显示“XX客户请求连接"? 是不是有什么有标准消息?也就是服务端如何感应到Connect消息,并在在静态控件上显示“XX客户请求连接"?
第二,问题二类似,当客户端要发送一个比如test.mp3的文件给服务端时,当客户端拖放到它的一个对话框区域时,服务端的某个区域就会显示“XX客户端发送数据,你是否接受”,当点接受时,就可以将文件接
受到服务断了,请问服务端是怎样感应客户端发送数据这个消息,从而在某个控件上显示“XX客户端发送数据,你是否接受””,是不是要在什么标准的消息处理体函数中添加““XX客户端发送数据,你是否接受””的代
码?
第三,关于阻塞与非阻塞,设置超时连接是针对阻塞,还是非阻塞的?非阻塞就是调用后立刻返回,是不是意味着比如(COnnect),如果对方没有Accept()函数,这个非阻塞函数调用后会立刻失败,而阻塞则一
直停滞在哪里? 传送与接受数据是不是应该用阻塞的?
第四,总之服务端在还没有与客户端建立连接之前,感应到客户端的Connect函数,或者,客户端一调用Connect函数,服务端在Accept之前,能够在适当的时候发出响铃,直到服务端Accept() 展开
我有以下几个问题不是很明白?
第一,假设我做了一个网络通信的客户端,和服务端,现在各种初始化工作已经做好,现在服务端已经启动服务,现在客户端向服务端发送请求连接,问题来了,怎样在服务端的某个静态控件域显示客户端的连
请求信息,比如,客户端一调用Connect函数,服务端某个静态控件上显示“XX客户请求连接",然后服务端点击”接受连接“控件后,这个静态控件上又显示”你已经接受XX 的请求连接",然后会话。问题是服务端怎样
知道客户端什么时候调用了Connect的连接请求函数,从而在静态控件上显示“XX客户请求连接"? 是不是有什么有标准消息?也就是服务端如何感应到Connect消息,并在在静态控件上显示“XX客户请求连接"?
第二,问题二类似,当客户端要发送一个比如test.mp3的文件给服务端时,当客户端拖放到它的一个对话框区域时,服务端的某个区域就会显示“XX客户端发送数据,你是否接受”,当点接受时,就可以将文件接
受到服务断了,请问服务端是怎样感应客户端发送数据这个消息,从而在某个控件上显示“XX客户端发送数据,你是否接受””,是不是要在什么标准的消息处理体函数中添加““XX客户端发送数据,你是否接受””的代
码?
第三,关于阻塞与非阻塞,设置超时连接是针对阻塞,还是非阻塞的?非阻塞就是调用后立刻返回,是不是意味着比如(COnnect),如果对方没有Accept()函数,这个非阻塞函数调用后会立刻失败,而阻塞则一
直停滞在哪里? 传送与接受数据是不是应该用阻塞的?
第四,总之服务端在还没有与客户端建立连接之前,感应到客户端的Connect函数,或者,客户端一调用Connect函数,服务端在Accept之前,能够在适当的时候发出响铃,直到服务端Accept() 展开
展开全部
我想楼主的问题可以用三次握手协议来解决。我自己先不才的介绍下我的想法,第一问题和第二个问题是一样的,服务器在建立连接以前会受到一个联接请求,在OnAccept函数中,你可以通过IP地址获取客户端用户的主机名称,也可以查看接受文件的名称,当然这个取决于,你自己程序怎么样去写。
非阻塞就是调用后立刻返回,但是会有返回的代码,如果正好那时候接受、或者发送完数据,函数返回成功代码,多数返回失败代码。传输的数据可以有其他函数继续发送,阻塞是直到数据发送或者接受成功才返回。如果你想继续了解这个机制,你可以去了解下二种模型和四种机制。
三次握手协议
所谓的“三次握手”即对每次发送的数据量是怎样跟踪进行协商使数据段的发送和接收同步,根据所接收到的数据量而确定的数据确认数及数据发送、接收完毕后何时撤消联系,并建立虚连接。为了提供可靠的传送,TCP在发送新的数据之前,以特定的顺序将数据包的序号,并需要这些包传送给目标机之后的确认消息。TCP总是用来发送大批量的数据。当应用程序在收到数据后要做出确认时也要用到TCP。
在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。 第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。 第二次握手:服务器收到syn包,必须确认客户的SYN(ac 三次握手k=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态; 第三次握手:客户端收到服务 器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。 完成三次握手,客户端与服务器开始传送数据,在上述过程中,还有一些重要的概念: 未连接队列:在三次握手协议中,服务器维护一个未连接队列,该队列为每个客户端的SYN包(syn=j)开设一个条目,该条目表明服务器已收到SYN包,并向客户发出确认,正在等待客户的确认包。这些条目所标识的连接在服务器处于 Syn_RECV状态,当服务器收到客户的确认包时,删除该条目,服务器进入ESTABLISHED状态。 Backlog参数:表示未连接队列的最大容纳数目。SYN-ACK重传次数服务器发送完SYN-ACK包,如果未收到客户确认包,服务器进行首次重 三次握手协议传,等待一段时间仍未收到客户确认包,进行第二次重传,如果重传次数超过系统规定的最大重传次数,系统将该连接信息从半连接队列中删除。注意,每次重传等待的时间不一定相同。 半连接存活时间:是指半连接队列的条目存活的最长时间,也即服务从收到SYN包到确认这个报文无效的最长时间,该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。
URG:紧急标志 紧急(The urgent pointer) 标志有效。紧急标志置位, ACK:确认标志 确认编号(Acknowledgement Number)栏有效。大多数情况下该标志 TCP三次握手是Syn Flood存在的基础位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1,Figure:1)为下一个预期的序列编号,同时提示远端系统已经成功接收所有数据。 PSH:推标志 该标志置位时,接收端不将该数据进行队列处理,而是尽可能快将数据转由应用处理。在处理 telnet 或 rlogin 等交互模式的连接时,该标志总是置位的。 RST:复位标志 复位标志有效。用于复位相应的TCP连接。 SYN:同步标志 同步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号,该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。在这里,可以把TCP序列编号看作是一个范围从0到4,294,967,295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。 FIN:结束标志 带有该标志置位的数据包用来结束一个TCP回话,但对应端口仍处于开放状态,准备接收后续数据。 服务端处于监听状态,客户端用于建立连接请求的数据包(IP packet)按照TCP/IP协议堆栈组合成为TCP处理的分段(segment)。 分析报头信息: TCP层接收到相应的TCP和IP报头,将这些信息存储到内存中。 检查TCP校验和(checksum):标准的校验和位于分段之中(Figure:2)。如果检验失败,不返回确认,该分段丢弃,并等待客户端进行重传。 查找协议控制块(PCB{}):TCP查找与该连接相关联的协议控制块。如果没有找到,TCP将该分段丢弃并返回RST。(这就是TCP处理没有端口监听情况下的机制) 如果该协议控制块存在,但状态为关闭,服务端不调用connect()或listen()。该分段丢弃,但不返回RST。客户端会尝试重新建立连接请求。 建立新的socket:当处于监听状态的socket收到该分段时,会建立一个子socket,同时还有socket{},tcpcb{}和pub{}建立。这时如果有错误发生,会通过标志位来拆除相应的socket和释放内存,TCP连接失败。如果缓存队列处于填满状态,TCP认为有错误发生,所有的后续连接请求会被拒绝。这里可以看出SYN Flood攻击是如何起作用的。 丢弃:如果该分段中的标志为RST或ACK,或者没有SYN标志,则该分段丢弃。并释放相应的内存。
非阻塞就是调用后立刻返回,但是会有返回的代码,如果正好那时候接受、或者发送完数据,函数返回成功代码,多数返回失败代码。传输的数据可以有其他函数继续发送,阻塞是直到数据发送或者接受成功才返回。如果你想继续了解这个机制,你可以去了解下二种模型和四种机制。
三次握手协议
所谓的“三次握手”即对每次发送的数据量是怎样跟踪进行协商使数据段的发送和接收同步,根据所接收到的数据量而确定的数据确认数及数据发送、接收完毕后何时撤消联系,并建立虚连接。为了提供可靠的传送,TCP在发送新的数据之前,以特定的顺序将数据包的序号,并需要这些包传送给目标机之后的确认消息。TCP总是用来发送大批量的数据。当应用程序在收到数据后要做出确认时也要用到TCP。
在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。 第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。 第二次握手:服务器收到syn包,必须确认客户的SYN(ac 三次握手k=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态; 第三次握手:客户端收到服务 器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。 完成三次握手,客户端与服务器开始传送数据,在上述过程中,还有一些重要的概念: 未连接队列:在三次握手协议中,服务器维护一个未连接队列,该队列为每个客户端的SYN包(syn=j)开设一个条目,该条目表明服务器已收到SYN包,并向客户发出确认,正在等待客户的确认包。这些条目所标识的连接在服务器处于 Syn_RECV状态,当服务器收到客户的确认包时,删除该条目,服务器进入ESTABLISHED状态。 Backlog参数:表示未连接队列的最大容纳数目。SYN-ACK重传次数服务器发送完SYN-ACK包,如果未收到客户确认包,服务器进行首次重 三次握手协议传,等待一段时间仍未收到客户确认包,进行第二次重传,如果重传次数超过系统规定的最大重传次数,系统将该连接信息从半连接队列中删除。注意,每次重传等待的时间不一定相同。 半连接存活时间:是指半连接队列的条目存活的最长时间,也即服务从收到SYN包到确认这个报文无效的最长时间,该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。
URG:紧急标志 紧急(The urgent pointer) 标志有效。紧急标志置位, ACK:确认标志 确认编号(Acknowledgement Number)栏有效。大多数情况下该标志 TCP三次握手是Syn Flood存在的基础位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1,Figure:1)为下一个预期的序列编号,同时提示远端系统已经成功接收所有数据。 PSH:推标志 该标志置位时,接收端不将该数据进行队列处理,而是尽可能快将数据转由应用处理。在处理 telnet 或 rlogin 等交互模式的连接时,该标志总是置位的。 RST:复位标志 复位标志有效。用于复位相应的TCP连接。 SYN:同步标志 同步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号,该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。在这里,可以把TCP序列编号看作是一个范围从0到4,294,967,295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。 FIN:结束标志 带有该标志置位的数据包用来结束一个TCP回话,但对应端口仍处于开放状态,准备接收后续数据。 服务端处于监听状态,客户端用于建立连接请求的数据包(IP packet)按照TCP/IP协议堆栈组合成为TCP处理的分段(segment)。 分析报头信息: TCP层接收到相应的TCP和IP报头,将这些信息存储到内存中。 检查TCP校验和(checksum):标准的校验和位于分段之中(Figure:2)。如果检验失败,不返回确认,该分段丢弃,并等待客户端进行重传。 查找协议控制块(PCB{}):TCP查找与该连接相关联的协议控制块。如果没有找到,TCP将该分段丢弃并返回RST。(这就是TCP处理没有端口监听情况下的机制) 如果该协议控制块存在,但状态为关闭,服务端不调用connect()或listen()。该分段丢弃,但不返回RST。客户端会尝试重新建立连接请求。 建立新的socket:当处于监听状态的socket收到该分段时,会建立一个子socket,同时还有socket{},tcpcb{}和pub{}建立。这时如果有错误发生,会通过标志位来拆除相应的socket和释放内存,TCP连接失败。如果缓存队列处于填满状态,TCP认为有错误发生,所有的后续连接请求会被拒绝。这里可以看出SYN Flood攻击是如何起作用的。 丢弃:如果该分段中的标志为RST或ACK,或者没有SYN标志,则该分段丢弃。并释放相应的内存。
参考资料: http://baike.baidu.com/view/1003841.htm
展开全部
第一,当客户端向服务器调用Connect()时,服务器Socket会收到OnAccept()消息,此时可以让用户决定是否接受连接;服务器调用Accept()函数后,客户端与服务器都会触发OnSend()消息相应函数。OnSend()函数就是连接成功的消息响应函数,表示连接建立成功,可以发送内容了。
第二,客户端给服务器发送一个字符串(如:"*File*test.mp3"),服务器在OnReceive()函数中调用Receive()函数收到这条字符串,知道是要传一个文件(名为test.mp3),显示出来询问用户是否接收。用户同意后,向客户端发送一个统一的讯息(如:"*File*test.mp3*Accept"),客户端收到信息后,正式开始发送文件。
第三,阻塞函数(如Connect)是等待直到对方回应或者超时才返回,返回值有效;非阻塞函数(如Connect)立即返回,返回值基本相同,不是真正的返回值。
非阻塞函数只是开了另外一个线程去等待返回,真正的函数执行完全时(对方回应或者超时)会有系统消息通知(如OnConnect()函数就是非阻塞时系统对连接操作的结果的返回,在这个函数中可以真正检测连接是否成功)。非阻塞函数仍然会完成预定功能,只是当前线程不停止,继续做别的事。一般来说异步(非阻塞)比同步(阻塞)要好,这样窗口不会失去响应,除非有些事情必须同步去做才会用阻塞的类的函数。传送与接收完全可以用异步(非阻塞的),这样可以同时传送多个文件。
第四,见第一条。
还有问题欢迎继续提问,用百度Hi聊天亦可。
第二,客户端给服务器发送一个字符串(如:"*File*test.mp3"),服务器在OnReceive()函数中调用Receive()函数收到这条字符串,知道是要传一个文件(名为test.mp3),显示出来询问用户是否接收。用户同意后,向客户端发送一个统一的讯息(如:"*File*test.mp3*Accept"),客户端收到信息后,正式开始发送文件。
第三,阻塞函数(如Connect)是等待直到对方回应或者超时才返回,返回值有效;非阻塞函数(如Connect)立即返回,返回值基本相同,不是真正的返回值。
非阻塞函数只是开了另外一个线程去等待返回,真正的函数执行完全时(对方回应或者超时)会有系统消息通知(如OnConnect()函数就是非阻塞时系统对连接操作的结果的返回,在这个函数中可以真正检测连接是否成功)。非阻塞函数仍然会完成预定功能,只是当前线程不停止,继续做别的事。一般来说异步(非阻塞)比同步(阻塞)要好,这样窗口不会失去响应,除非有些事情必须同步去做才会用阻塞的类的函数。传送与接收完全可以用异步(非阻塞的),这样可以同时传送多个文件。
第四,见第一条。
还有问题欢迎继续提问,用百度Hi聊天亦可。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
楼主,建议你看看五种WinSocket IO中,CSocket用Onaccept()封装了,FD_SOCKET消息,有个WSAselect什么函数,你看看嘛,我想这个适合你看.把你的邮箱发给我通过百度hi,我把五种IO模型发给你
本回答被提问者采纳
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
...winsock.我也算是学习socket2年了.也总算写得出健壮的不出错的socket server和client.学会了sock 5大io模型,其实很多网络编程的书都没讲到一些细节.而这些细节会导致你写程序时,发觉会出问题.往往高手都不说这些秘密.我也是写了程序自己反复调试才确定真相的.真相只有自己去发掘了.
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
展开全部
干脆写一个给你参考啦。。。
已赞过
已踩过<
评论
收起
你对这个回答的评价是?
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询