服务器的异步与同步套接字 [英] Async vs Sync Sockets for Server

查看:158
本文介绍了服务器的异步与同步套接字的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

大家好,
只是以为id会问你们对我正在做的事情的想法.

基本上希望开发一种将接受TCP连接的服务器.客户端不会一直保持连接状态,即客户端打开连接,将数据发送到服务器,服务器将发送回ack,nak或某些数据,然后客户端关闭.

服务器将要服务的客户端数量大约为1000-2000,但是我希望知道它可以与更多的功能一起工作(-).

从时间的角度来看,来自客户端的连接是完全随机的,因此,从理论上讲,服务器在任何时候都可能受到100个请求的攻击.<​​br/>
所以我的问题是,你们认为对于服务器端套接字,最好的选择是什么?异步?同步吗?

我还要提到的另一件事是,服务器接收到的数据将需要被推送到SQL数据库中.

期待您有任何意见:-)

Hi all,
just thought id ask you guys for your thoughts on something i''m looking into doing.

Basically looking to develop a Server that will accept TCP connections. The clients will not be connected constantly, i.e the clients open connection, send data to the server, the server will send back ack, nak or some data and then the client closes.

The amount of clients the server will have to service will be around 1000-2000, but i would like the confidence of knowing it would work with more :-).

The connections from the clients will be totally random with regards to time thus, in theory there is a possibility that the server could get hit with 100s of requests at any instance in time.

So my question is what do you guys think the best route to take is for the server side sockets is ? Async ? Sync ?

Also another thing i should mention is the data the server receives will need to be pushed into a SQL database.

Look forward to any comments you have :-)

推荐答案

我认为每个人都应该更喜欢依赖于线程的同步API.例如,网络服务通常只需要两个线程即可使用套接字,我称之为侦听线程"和应用协议线程".通常,最好的TCP API是TcpListener/TcpClient.侦听线程正在侦听新连接,接受新连接并将新获得的客户端套接字(代表服务主机上已连接远程套接字的对象)放入线程之间共享的某个集合中.应用程序协议线程正在从网络流中读取/写入网络流,以遵循某些应用程序级协议.可以处理从任一方断开的连接,以从集合中删除项目,因此不需要正常断开连接.当然,您需要使用适当的线程同步原语.

同样,客户端部分需要一个单独的线程来与套接字一起使用.

另请参阅我过去的解决方案:在c#和套接字编程中使用api [ ^ ].

坦率地说,我不知道异步API可能比自定义线程更受青睐的情况.线程更易于编程,并提供更显式且细粒度的控制.我认为在线程技术不常见的情况下,异步API是提供给开发人员的,因为现在和现在它仅对支持遗留代码有用.无需将其用于新开发.

—SA
I think everyone should prefer synchronous API relying on your threads instead. For example, a network service typically need just tow thread to work with sockets, let me call them "listening thread" and "application protocol thread". Usually the best TCP API is TcpListener/TcpClient. The listening thread is listening for new connections, accepts them and put obtained client sockets (objects representing connected remote sockets on the service host) and put it in some collection shared between threads. The application protocol thread is reading/writing from/to network stream to follow some application-level protocol. A disconnection from either side could be processed to remove an item from the collection, so no graceful disconnection is needed. Of course you need to use appropriate thread synchronization primitives.

Same way, the client part needs a separate thread to work with sockets, just one.

See also my past solution: using api in c# and socketprogramming[^].

Franky, I don''t know situation where asynchronous APIs could be preferred over custom threads. Threads are easier to program and provide more explicit and fine-grain control. I think asynchronous APIs were offered to developers when threading was not a common place as it is now and now is only useful to support legacy code. No need to use it for new development.

—SA


这篇关于服务器的异步与同步套接字的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆