高度可靠的交易/信号复制器(意识形态的讨论和发展) - 页 7

 

好的。 那么我建议把套接字连接作为一个工作模式。

Схема работы синхронизатора:

- 服务器将与客户建立永久的套接字连接(为每个客户分配自己的线程的问题仍在考虑之中)。
- 主客户在交易事件中发送其订单的当前状态
- 服务器保存该文件并立即发送给所有其他客户(已经建立了套接字连接)。
- 客户端收到文件并根据收到的数据改变订单状态。
- 当一个新的客户端连接时,向导最后保存的文件也会被发送到客户端。(用于初始同步)

这个系统的主要优点是节省交通
- 它不需要客户的不断请求。它将从服务器接收它们的可用性
- 同样地,主客户端只有在检测到变化时才会发送数据

在连接中断的情况下提供保护
- 客户端每隔5秒发送一个 "心跳 "数据包(例如2个字节),以检查与服务器的通信。
- 如果数据包发送不成功(无应答),客户端会重新初始化连接。
- 服务器也是如此。 如果在10秒内没有收到来自客户端的响应,套接字连接将被关闭。


这种连接有什么缺点吗?
- 例如,可用的套接字连接的最大可能数量是多少?
 
sergeev:

在失去连接的情况下提供保护
- 客户端每隔5秒发送一个 "心跳 "数据包(例如2个字节),以检查与服务器的通信。

在通过TCP/IP传输协议进行通信时,绝不会这样做,因为通信是在套接字层自动维持的,即由操作系统维持。在连接中断的情况下,会在客户端抛出一个异常,其处理程序必须说明在这种情况下到底需要做什么。就服务器而言,它并不关心,因为如果客户端断开连接,那是客户端的问题。

sergeev:


- 例如,可用的套接字连接的最大可能数量是多少?
对于一个IP地址上的主机,最多可以使用65536个端口,其中一些已经被其他互联网连接占用。而一个端口将始终被服务器套接字占用,用于监听。
 
Reshetov:

如果连接被破坏,并且在客户端引发了一个异常,必须在其处理程序中引发一个异常

你说的是哪个例外?
我说的是WS2_32.dll。 通常的Berkeley套接字(虽然是异步的)。没有看到那里有任何例外。你只能通过尝试发送/接收来检测一个崩溃。

一个主机上的一个IP最多可以使用65537个端口,其中一些端口已经被其他互联网连接所占用。
嗯,你只需要一个端口。
这个端口上可以有多少个套接字连接?
 
sergeev:

你说的是哪个例外?
我说的是WS2_32.dll。 普通的Berkeley套接字(虽然是异步版本)。没有看到那里有任何例外。你只能通过尝试发送/接收来检测一个崩溃。

嗯,你只需要一个端口。
我感兴趣的是这个端口可以连接多少个套接字?

每个端口只有一个连接。为了使客户端能够连接,它必须知道服务器上分配了什么IP和端口号。或者,你可以指定一个域名而不是IP,套接字将通过DNS将其解析为一个IP地址。

服务器套接字对这个端口号进行监听,以便从客户端进行连接。当客户端连接时,套接字将从空闲的端口池中给它另一个端口以保持连接。然后,该持久性端口再次被释放,并监听其他客户的连接。

这就是TCP/IP传输协议连接的方式。所有这些都是在套接字层完成的,也就是说,该协议不需要编程--它是标准的,并且已经硬连接到操作系统的共享库中。

 
有的东西可能会在发展中派上用场
附加的文件:
kopir.zip  397 kb
 
Reshetov:
当客户端连接时,套接字 从空闲端口池中分配另一个端口,以保持其永久连接。

尤里,谢谢你的基本知识,但这是不合适的。 你给的是错误的知识。

而分配的那个根本就是胡说八道,对不起。 也许你是在两个不同的假设中应用港口概念,但这样你最好是在公认的概念中工作。

 
SEVER11:
有的东西可能会在发展中派上用场

不太可能。不专业。
 
sergeev:


而突出显示的那个是无稽之谈,对不起。 也许你是在以两种不同的名义应用港口概念,但那样的话,你最好在公认的概念中工作。

正如他们所说,你如何应用港口的概念是你自己的问题。我只解释了TCP/IP协议中如何使用端口。再说一次,这个协议是标准的,也就是说,我没有发明它。

我不是那个发明它的人。

好运!

 
sergeev

网络规模的顺序是什么,有多少客户应该是1000-000,100-000,10-000,1-000?

因为你的服务器真的会因为成千上万的客户而破产。

 
Urain:

网络规模的顺序是什么,有多少客户应该是1000-000,100-000,10-000,1-000?

因为你的服务器真的会因为成千上万的客户而破产。


这就是问题所在,我正在努力全面地思考。当然,你必须在初期投入大量的可扩展性。也就是说,目标是在1000小时内做同样多的事情。而且,只有少数人以后会使用它,这并不重要。

这就是为什么我现在试图选择并下定决心--要么是速度,要么是有插座的微交通。或者是http和大量的流量在不断追逐客户的新部分信息。