套接字在一端断开连接,防火墙?

发布于 2024-08-05 03:41:03 字数 730 浏览 2 评论 0原文

我有一个 C# 应用程序,已经运行良好好几年了。它通过 TCP/IP 套接字连接到向我发送股票交易执行的机器。

最近,我尝试将其部署到位于硬件防火墙后面的新数据中心中的一些机器上,并且我开始看到一些奇怪的断开连接。

当发生断开连接时,在我的应用程序(客户端)中,除了停止通过套接字接收数据之外,我没有看到任何异常。 Wireshark 确认没有数据到达套接字,并且当我在调试器中停止应用程序的接收线程时,它正在阻塞 Receive() 调用。套接字在 netstat 中显示为 ESTABLISHED。

但从服务器端来看,我的客户端似乎已断开连接。查看他们的日志,看起来他们一端的套接字通常以 (nRecvd=-1,errno=104) 或 (nRecvd=0,errno=11) 结束。 (104 是对等方重置连接)。

断开连接似乎仅在一段时间不活动后才会发生。我现在已经解决了这个问题,方法是在客户端和服务器之间实现心跳,每 20 秒发送一条短消息并获得回复。这导致过去几天的断开连接数降至 0。

起初,我认为是硬件防火墙的问题。它导致套接字在不活动后超时。但防火墙负责人声称该端口(8887)的连接超时时间为2160分钟。

我运行的是 Windows Server 2003 和 .NET 3.5。交易服务器是一台 Linux 机器(我相信是 sles9,尽管我不确定)。

对可能发生的事情有什么想法吗?鉴于我无法访问防火墙日志并且无法更改交易服务器上的代码,我可以做些什么来进一步调试这个问题?

谢谢, 麦克风

I have a C# application that has been running fine for several years. It connects via a TCP/IP socket to a machine that sends me stock trade executions.

Recently, I've tried to deploy it to some machines in a new data center that is behind a hardware firewall, and I've started to see some weird dis-connects.

When a dis-connect happens, in my app (the client side), I see nothing unusual except that I stop receiving data over the socket. Wireshark confirms that no data is reaching the socket and my application's receive thread is blocking on the Receive() call when I stop it in the debugger. The socket shows as ESTABLISHED in netstat.

But from the server side, it looks like my client is dis-connecting. Looking at their logs, it looks like the socket on their end usually ends up with either (nRecvd=-1,errno=104) or (nRecvd=0,errno=11). (104 is connection reset by peer).

The dis-connect only seems to happen after a period of in-activity. I have solved this for now by implementing a heartbeat between my client and their server that just sends a short message every 20 seconds and gets a reply. This has caused the dis-connects to drop to 0 over the past few days.

At first, I figured that the hardware firewall was the problem. It was causing the socket to time out after in-activity. But the person in charge of the firewall claims that the timeout for connects on this port (8887) is 2160 minutes.

I am running Windows Server 2003 and .NET 3.5. The trades server is a linux machine (sles9 I believe though I'm not sure).

Any ideas on what might be going on? What could I do to debug this more given that I don't have any access to the firewall logs and no ability to change the code on the trade server?

Thanks,
Mike

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

梦中楼上月下 2024-08-12 03:41:03

您所描述的内容很常见,并且像您一样通过此类防火墙/网关实现心跳以保持 TCP 套接字保持活动状态是很常见的。

该硬件可能有 2160 分钟的硬超时(根据我的经验,20-30 分钟更常见),但如果有任何类型的负载,连接通常会更频繁地断开。此类防火墙的资源有限,当它们需要更多连接跟踪时,它们往往会丢弃跟踪的最旧的连接,而无需任何活动,无论硬超时设置如何。

如果您想进一步调试,请在防火墙的服务器端进行嗅探,看看当服务器断开连接时会发生什么(如果有的话)

What you describe is common, and it's common to implement a heartbeat to keep TCP sockets alive through such firewalls/gateways like you did.

That hardware might have hard 2160 minutes timeouts (in my experience 20-30 minutes is more common though) , but connections are usually dropped much more aggressively if there's any kind of load. Such firewalls have limited resources, and when they need more connection tracking they tend to drop the oldest connection tracked without any activity regardless of the hard timeout set.

If you want to debug this more, go sniff on the server side of the firewall and see what , if anyting, happens when the server gets a disconnect

烛影斜 2024-08-12 03:41:03

我会在防火墙的两侧设置wiresharp,以查看TCP(和较低级别)上发生的情况。
当管理员说“连接超时”时。这是空闲、已建立的连接的超时吗?我想其他任何事情都没有任何意义。

另外,您是否使用 TCP 的 KeepAlive 选项?是否由防火墙转发?

正如我所说,可能想在防火墙的两侧运行wireshark......

I would setup wiresharp on both sides of the firewall to see what happens on TCP (and lower level).
And when the admin says the "timeout for connects" is something. Is that the timeout for an idle, established connection? Anything else does not make any sense I guess.

Also, are you using KeepAlive option for TCP? And is that forwarded by the firewall or not?

As I said, probably want to run wireshark on both sides of the firewall...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文