Socket编程

[luluyy]

最近想用Socket搞个程序 就是实向 客户端收集客户录入的消息，最后拼成sql 或把数据格式化带上操作类型[插入？删除？更新？]发送到服务器端，服务器端接收消息操作数据库，并给指定的客户端返回结果，遇到了以下两个问题，请大虾指教
1、发送给客户端消息后，服务器端怎么通知刚才发消息的客户端啊？客户端一直用等待窗口等着吗？
2、在网上看到的例子 都是启动了以后有一个while(true) 这样的东西处理消息，这样靠谱吗？能支撑多少客户端并发呀？

有没有这方面的例子呢？

[luluyy]

引用 1 楼 diaodiaop 的回复:

while(true) 是同步的.. 有beginXXX 是异步的 并发可以达到几万差不多了. 另外客户端也是有bigin异步接收消息的. http://www.cnblogs.com/chenxizhang/archive/2011/09/10/2172994.html 看下这个 对刚学socket有很大帮助的

嗯 很有用，请问我如果有1000万个客户端 都是插入数据库的操作，应该用while 还是begin呢 客户端发过去以后 怎么接收服务器返回的消息呢？就像在。NET中执行一个方法最后回返回结果一样 在返回前 程序是无法进行其它操作的

[showjim]

必须使用异步模式，保持长连接需要比较大的内存，比如一个Socket分配4K缓冲区，那么至少需要1000W*4K=40G内存。

[以专业开发人员为伍]

引用 2 楼 luluyy 的回复:

嗯 很有用，请问我如果有1000万个客户端

如果你是说的是长连接，不用想6万以上的数字。

[luluyy]

引用 4 楼 sp1234 的回复:

[quote=引用 2 楼 luluyy 的回复:] 嗯 很有用，请问我如果有1000万个客户端

如果你是说的是长连接，不用想6万以上的数字。[/quote] 如果使用异步 我把消息发出去以后 客户端应该处于什么状态？一直等待服务端给回馈消息吗？因为每一个操作最终是要弹出消息提示用户结果的

[luluyy]

引用 4 楼 sp1234 的回复:

[quote=引用 2 楼 luluyy 的回复:] 嗯 很有用，请问我如果有1000万个客户端

如果你是说的是长连接，不用想6万以上的数字。[/quote] 就是不知道应该用什么方式，如果是短连接 数据交互完成 断开连接以后 又想发数据，是不是每次都得再次发起连接。 我是不是可以这样理解 用户登录时与服务器一直保持连接，用长连接，各种消息操作使用短连接 有要操作数据就发起 完成之后断开连接 也就是说一直与服务器保持连接的只有用户登录，即服务器端可实时获得用户在线数之类的东西，如果这个连接断开 客户端将与服务器失联，数据操作之类的使用短连接 不知道我的理解是否正确 请指教

[於黾]

用长连接当然会比较方便,因为本来就是连接着的,通过这个连接将数据发回去就行了,也可以通过连接数判断在线数 但是如果用户数比较多的话,还是短连接 可以客户端也开一个监听,等着服务端连接回来. 服务端维持一个队列,客户端定期发心跳包给服务端,如果一段时间内没有收到心跳,就从队列里移除.

[於黾]

不过如果是客户端在局域网内,服务端在广域网中,短连接就不行了 服务器会找不到客户端在哪里.只能用长连接.

[luluyy]

引用 8 楼 Z65443344 的回复:

不过如果是客户端在局域网内,服务端在广域网中,短连接就不行了 服务器会找不到客户端在哪里.只能用长连接.

大概的设计是这样的 服务器端 有一个应用服务器 专门跑 服务端程序，服务端程序是外网IP，通过各种硬件与软件保护防止攻击吧 就不多说了 然后服务端程序与DB服务器是内网关系 客户端指不定是内网【家里接了路由器】还是外网【其他服务器】，客户端可以通过长连接连接到应用服务器 这个肯定没问题，服务器如果想要给客户端发消息通过长连接发送 然后客户端接收消息代码后处理消息，完成后再与服务器建立短连接 将处理完的消息与服务代码发送给应用服务器，这样的设计是否合理呢？

[luluyy]

还有大虾在么 指点一二啊

[於黾]

服务器如果想要给客户端发消息通过长连接发送 然后客户端接收消息代码后处理消息，完成后再与服务器建立短连接 将处理完的消息与服务代码发送给应用服务器，这样的设计是否合理呢？ 没看懂你这是什么设计思路 不是应该客户端将请求发到服务端,服务端处理好之后返回数据或成功失败之类的么 怎么是服务端给客户端发消息,客户端去处理?

[於黾]

1.客户端对服务端建立长连接,发送登录信息 2.客户端将请求或相应数据发给服务端(如果是查询就只有请求,如果是插入或更新要连数据一起发送) 3.服务端接到请求后先验证客户端是否登录等等,然后去执行请求 4.服务端将执行结果(如果是查询则是数据)通过长连接发回客户端 5.客户端关闭前断开长连接 如果用户很多,也可以发送数据前建立长连接,接到返回结果后关闭长连接 但是肯定不能用短连接(就是发送完马上关闭,那就接收不到返回结果了,服务器没地方找客户端去)

[luluyy]

引用 12 楼 Z65443344 的回复:

1.客户端对服务端建立长连接,发送登录信息 2.客户端将请求或相应数据发给服务端(如果是查询就只有请求,如果是插入或更新要连数据一起发送) 3.服务端接到请求后先验证客户端是否登录等等,然后去执行请求 4.服务端将执行结果(如果是查询则是数据)通过长连接发回客户端 5.客户端关闭前断开长连接 如果用户很多,也可以发送数据前建立长连接,接到返回结果后关闭长连接 但是肯定不能用短连接(就是发送完马上关闭,那就接收不到返回结果了,服务器没地方找客户端去)

是不是说 用户登录 这个是长连接 只在客户端在线就保持连接 增、删、改、查 这些的用的是短连接 例如查询： 查询时先建立短连接 然后发送数据给服务器 服务器找到数据后给客户端 然后客户端接收数据并断开连接 是这样的吗亲

[於黾]

引用 13 楼 luluyy 的回复:

是不是说 用户登录 这个是长连接 只在客户端在线就保持连接 增、删、改、查 这些的用的是短连接 例如查询： 查询时先建立短连接 然后发送数据给服务器 服务器找到数据后给客户端 然后客户端接收数据并断开连接 是这样的吗亲

你如果已经建立了长连接,就不要再建立短连接了亲 难道你的长连接只是做登陆并维持心跳,剩下什么活都不干?

[xian_wwq]

引用 楼主 luluyy 的回复:

最近想用Socket搞个程序 就是实向 客户端收集客户录入的消息，最后拼成sql 或把数据格式化带上操作类型[插入？删除？更新？]发送到服务器端，服务器端接收消息操作数据库，并给指定的客户端返回结果，遇到了以下两个问题，请大虾指教 1、发送给客户端消息后，服务器端怎么通知刚才发消息的客户端啊？客户端一直用等待窗口等着吗？ 2、在网上看到的例子 都是启动了以后有一个while(true) 这样的东西处理消息，这样靠谱吗？能支撑多少客户端并发呀？ 有没有这方面的例子呢？

Windows提供了选择（Select）、异步选择（WSAAsyncSelect）、事件选择（WSAEventSelect）、重叠I/O（Overlapped I/O）和完成端口（Completion Port)共五种I/O模型。 给个链接供参考： http://blog.csdn.net/woshinia/article/details/8585930

[laizhiping_rj]

http://download.csdn.net/detail/laizhiping_rj/7903997 CSR-Socket 支持超大规模连接，基于iocp、缓存队列，封装数据包，解决粘包

[zhenggudu]

就始终保持长连接就好了，当然也可以在多少时间不操作的时候就断开连接 如果单单只要客户端提交数据的话，就创建一个长连接 客户端写入，服务端读取并处理数据，然后再返回结果给客户端这样比较简单 如果用户体验要好一点的话，客户端可以另外开一个线程，采用队列的方式发送和返回数据 这样不会造成程序阻塞

[以专业开发人员为伍]

引用 13 楼 luluyy 的回复:

是不是说 用户登录 这个是长连接 只在客户端在线就保持连接 增、删、改、查 这些的用的是短连接 例如查询： 查询时先建立短连接 然后发送数据给服务器 服务器找到数据后给客户端 然后客户端接收数据并断开连接 是这样的吗亲

不是。 我猜你现在能够想到的，其实都可以是“短连接”。凡是“一问一答”方式的，都可以是短连接。因为这时客户端发起消息，然后等待服务器给出“一个”应答消息。就是这种模式。 在这个情况下，长连接跟短连接的最主要区别就是性能问题。长连接方式肯定会比短连接方式快至少一倍速度，特别是每秒的通讯事务数据超过10次以上的时候。 长连的更多的作用，是支持服务器向客户端不定期地推送消息。如果你没有这方面的设计需求，比如说做个办公室里的小OA程序已经感觉很有成就感，这时候可能就不会去注重“服务器push”，不会考虑长连接。 不论是长连接还是短连接，客户端在发送数据的时候都可以“异步、多线程”处理，以便释放主线程，让用户界面交互操作有“流畅”的感觉。

[以专业开发人员为伍]

长连接方式比短连接方式在编程中稍微复杂一点。因为长连接方式下起码要能做到以下两点： 1. 要能够在一大堆 bytes 字节中区分出多个消息的起止位置来。 2. 当不断发送多个消息时，对于对方发送来的返回消息，应该能够“配对”。比如客户端按照次序“1、2、3、4、5”发送5个消息，然后服务器按照“5、2、1、4、3”的顺序发送回来返回消息，其中等到5的返回消息用了10毫秒，而等到4的返回消息用了900号面，客户端就应该每当收到了一个完整的返回消息（其它消息可以还没有接收完整）时，就立刻找到当初这个消息注册的回调方法，去异步回调客户端处理方法。 至少要完成上述两个功能，你才应该敢于去进行长连接通讯。否则就使用简单好用的短连接方式就行。实际上是用 HTTP 页面通讯方式也是一种非常可靠的短连接方式，不一定直接使用底层 TCP 自定义方式。

[以专业开发人员为伍]

引用 5 楼 luluyy 的回复:

如果使用异步 我把消息发出去以后 客户端应该处于什么状态？一直等待服务端给回馈消息吗？因为每一个操作最终是要弹出消息提示用户结果的

你这个话是自相矛盾的，这其实反映了你对于“异步”概念的了解程度。 一旦我们说“异步”，我们就是指不去“等待回馈”，而是（在子线程或者主线程出现的）回调事件。软件工程师如果一提到术语就明白深一点层次的机制的要求，那才好进一步设计程序流程。 其实使用脚本、使用 jQuery 的 ajax 方法人都知道异步回调然后给用户提示的机制的。一个号称“Socket编程”的人不如只用写网页 ajax 代码的人更理解异步机制，就惨了。

[luluyy]

引用 18 楼 sp1234 的回复:

[quote=引用 13 楼 luluyy 的回复:] 是不是说 用户登录 这个是长连接 只在客户端在线就保持连接 增、删、改、查 这些的用的是短连接 例如查询： 查询时先建立短连接 然后发送数据给服务器 服务器找到数据后给客户端 然后客户端接收数据并断开连接 是这样的吗亲

不是。 我猜你现在能够想到的，其实都可以是“短连接”。凡是“一问一答”方式的，都可以是短连接。因为这时客户端发起消息，然后等待服务器给出“一个”应答消息。就是这种模式。 在这个情况下，长连接跟短连接的最主要区别就是性能问题。长连接方式肯定会比短连接方式快至少一倍速度，特别是每秒的通讯事务数据超过10次以上的时候。 长连的更多的作用，是支持服务器向客户端不定期地推送消息。如果你没有这方面的设计需求，比如说做个办公室里的小OA程序已经感觉很有成就感，这时候可能就不会去注重“服务器push”，不会考虑长连接。 不论是长连接还是短连接，客户端在发送数据的时候都可以“异步、多线程”处理，以便释放主线程，让用户界面交互操作有“流畅”的感觉。[/quote] 谢谢大虾 我再研究研究