这是一个创建于 1360 天前的主题，其中的信息可能已经有所发展或是发生改变。
场景
现有大概 2000 多张图片采用 UDP 方式从客户端发送到服务器端,需要在服务器端显示
问题
发送的时间很短,在短时间内服务器端无法接受大量的数据(好像是 socket 自带的缓冲区不够?), 在 TCP 链接中可以采用
int conn = accept(m_socketfd, (struct sockaddr*)&m_servaddr, &len);
m_li.push_back(conn);
的方式缓存,但是在 UDP 模式下好像不支持 accept 函数, 问题是如何在 UDP 场景下,让服务器可以缓存从客户端发来的数据,并逐张显示图片.
吐槽
从进公司干到现在,已经干过了 java, golang, python. C++.美名曰算法工程师,其实就是个打杂的,我吐了.
 |
1
MekoPan OP 或者有没有其他思路解决传输大数据的问题
|
 |
2
0TSH60F7J2rVkg8t 2021-04-06 17:37:05 +08:00
udp 是不可靠的协议，在链路上，包括但不限于你的计算机-中间路由器-对方的计算机，任何一方缓存满了，新到的包都直接丢弃，你无法保证客户端能收到大量数据。如果需要收发大量数据，你需要实现自己的可靠传输方案。
|
|
3
0TSH60F7J2rVkg8t 2021-04-06 17:39:08 +08:00  1
可以参考这些协议：UDT 、KCP 、QUIC 、uTP 、FASP 、SCTP
https://zhuanlan.zhihu.com/p/68466363 |
 |
5
ch2 2021-04-06 17:42:03 +08:00 via iPhone 1
udp 没有 accept，听起来你要实现的是 ftp over udp，工作量挺大的
|
 |
6
hxndg 2021-04-06 17:44:59 +08:00 1
UDP 是不缓存吧，
而且讲道理你如果想做缓存需要在 UDP 上层做这个操作，别指望了 UDP 了 而且都用 SOCKET 了为啥不用 TCP 呢？ 当然 TCP 也不能完全解决你的问题 |
 |
7
neoblackcap 2021-04-06 17:45:18 +08:00 1
一般公司就不要考虑 SCTP 了，去看看 KCP 吧或者 QUIC 吧。那两个都挺好，挺成熟的
|
|
9
MekoPan OP @neoblackcap 主要明天要验收,现在改来不及了
|
|
11
MekoPan OP @ch2 如果是 2000 个坐标点数据,一个点一个点传输呢? 我自己测试的效果是,传输时间很短,但是我服务器接受之后只能接收到大概 300 多个数据.
|
 |
12
toss156 2021-04-06 18:06:24 +08:00 1
用 kcp 在 udp 的基础上包一层就可以了，记得改大 kcp 窗口和 udp 发送缓冲区。kcp 来控制重传。
|
 |
13
xmcy0011 2021-04-06 18:09:25 +08:00 1
你这个说的有点模糊啊，2000 张图片是同时传还是 1 个 1 个传。你要是同时传，服务器带宽都是问题吧？还有你有几台服务器？一台不够，分流啊，多搞几台。
|
|
14
ch2 2021-04-06 18:27:25 +08:00 1
@MekoPan #11 你每次传的时候要在数据前面加个 header，注明这是哪个文件的哪一块数据。不管是 tcp 还是 udp 在其之上再自定义传输格式才能保证你知道哪一块数据漏了要求客户端补上，不要指望不约定传输格式瞎发瞎收就能撞大运把数据传完整
|
 |
15
araaaa 2021-04-06 19:02:33 +08:00 via iPhone
???并不适合用 udp 去做
|
Select Language