How to read data from socket, until client stopped send?

huangapple go评论92阅读模式
英文:

How to read data from socket, until client stopped send?

问题

我有一些问题。
我有一个客户端和服务器。客户端通过TCP连接服务器。
然后,客户端发送一些数据(以块分隔),我不知道数据的长度(TLS握手)。但我知道客户端发送的数据有固定的长度,然后停止,直到收到一些响应,然后再次发送固定长度的数据。

我需要读取所有的数据块,直到客户端停止发送(因为有很多块)。如何做到这一点?

我只有一个想法,就是设置超时。在循环中读取数据,并在迭代之间设置超时。如果超时结束,那么数据就完整地被收集起来。

也许还有更优雅的解决方案?

英文:

I have some problem.
I have client and server. Client connect with server over TCP.
Then, client send some data (separated by chunks), I don't know what is the length of data (TLS handshake). But I know that client send some data with fixed length, and then stop, until not received some response, then he send data with fixed length again.

I need read all chunks, until client stopped send (because so many chunks). How to do that ?

I have only one idea, it's timeout. Read data in loop and set timeout between iterate. If timeout is ended, then data complete collected.

Perhaps there is a more elegant solution?

答案1

得分: 2

根据你的评论中的信息,你的做法是错误的。编写HTTPS代理的正确方法是读取CONNECT行,建立上游连接,向客户端发送适当的响应,然后如果成功,开始同时复制双向的字节。你不需要关心数据包或读取大小,也绝对不应该在重传之前尝试“收集”数据包,因为这只会增加系统的延迟。

你可以通过为每个连接启动两个线程,一个用于每个方向,或者通过非阻塞套接字和select()/poll()/epoll()等方式来实现。

但是,我完全不知道你为什么要这样做。已经有很多开源的HTTP代理存在,而且由于你处理的是HTTPS,你不可能为它们增加任何价值。你关于“业务逻辑”的说法是没有意义的,或者至少是无法实现的。

英文:

Based on the information in your comments, you're doing this wrong. The correct way to write an HTTPS proxy is to read the CONNECT line, make the upstream connection, send the appropriate response back o the client, and then if successful start copying bytes in both directions simultaneously. You're not in the least concerned with packets or read sizes, and you should certainly not make any attempt to 'collect' packets before retransmission, as that will just add latency to the system.

You can accomplish this either by starting two threads per connection, one in each direction, or via non-blocking sockets and select()/poll()/epoll(), or whatever that looks like in Go.

BUT I have no idea why you're doing this at all. There are plenty of open-source HTTP proxies already in existence, and as you're dealing with HTTPS there is no value you can possibly add to them. Your claim about 'business logic' is meaningless, or at least unimplementable.

huangapple
  • 本文由 发表于 2015年9月9日 03:05:31
  • 转载请务必保留本文链接:https://go.coder-hub.com/32465396.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定