mutouyun
channel 类型为<relat::multi, relat::multi, trans::broadcast> ，运行一段时间后接收端掉线，无法接收数据
你好 mutouyun, 我发现channel 是<relat::multi, relat::multi, trans::broadcast> 时，运行demo中的send_recv 例子，./send_recv send 102400 100 发送端启动命令，运行一会后客户端就被踢掉了，服务端log "fail: send, there is no receiver on this connection." 但是如果channel 是<relat::single, relat::multi, trans::broadcast> 发送端 可以发送更大的数据并且 时间间隔更小甚至循环发送，间隔时间为0都没有问题，此时接收端仍然可以正常接收数据，这两个结果差距太大了，为什么在channel 是<relat::multi, relat::multi, trans::broadcast> 性能这么弱？
另外一个问题是try_send 和 send，这个两个接口的区别就是send 在阻塞并且超时后会踢掉阻塞的客户端，但是try_send 并不会踢掉客户端？ 我把demo中的send_recv 例子里面的send 换成了try_send ，当try_send 失败后确实没有踢掉客户端，当try_send 失败后sleep 1秒， 但是接收端仍然不能接收数据，与被踢掉的现象一样，这个是一个正常的现象么？
神奇。。我现在还在加班，明天有空看一下。。 虽然mmb性能确实比smb弱一点，但也不至于如此。
try_send是队列满了不强制发送，如果队列满了，说明接收端一直没收数据，按正常情况来说，接收端不应该这样。 所以如果接收端本来就不能收数据了，用try_send并不能让它恢复的。
目前的ipc在对共享内存的退出保护上做得很不够，我会在重构的时候重点思考下怎么增加鲁棒性。
我就是用的demo中的 send_recv 例子，只修改了channel 类型，其他都没有修改，进行的测试。在x86平台上确实不容易出现，可以将发送间隔继续缩短尝试下。
我还有个问题请教下，就是我发现当程序异常推出的时候可能会残留文件，有时候会影响程序的再次运行，所以我自己作了个机制去删除残留共享文件，但是我发现有两个共享文件并不是由创造channel 时传入的name 组成的，而且当存在多个发送端和接收端的时候这两个文件只有一份，“IPC_SHM____CA_CONN” 和 “__IPC_SHM____CHUNK_INFO__1024” ，如果程序异常推出了，这两个文件不进行删除，其他的以创造channel 时传入的name 组成的文件全部删除掉了，当程序重新启动后会不会产生一些影响？多谢@mutouyun
你好mutouyun，目前遇到了一个问题，我发送的数据大小会经常变化，就产生了非常多的 __IPC_SHM____CHUNK_INFO__xxx 文件。我通过修改 enum : std::size_t { data_length = 64, large_msg_limit = data_length, large_msg_align = 1024, large_msg_cache = 32, }; 这个枚举中的字段是否可以控制，减少些__IPC_SHM____CHUNK_INFO__xxx 文件的生成？ 当前的配置中超过64字节就会用新建临时的共享内存 发送，就会产生新的__IPC_SHM____CHUNK_INFO__xxx 文件是这个意思么？ 至于large_msg_align 和 large_msg_cache 的含义是什么？多谢@mutouyun
我其实在wiki里有写这个 https://github.com/mutouyun/cpp-ipc/wiki/%E5%85%A8%E5%B1%80%E5%B8%B8%E9%87%8F%E5%AE%9A%E4%B9%89