evpp
evpp copied to clipboard
Qihoo360
How to transfer large buffer by TCPConn...
As the title...
Anyone can provide a demo, how to transfer large buffer and deal with the event OnMessage...
In other words, can TCPConn ensure that it is send(buffer) once and OnMessage(buffer) once?
When the buffer is too large, the upper layer user seems to need to deal with the packege sticky/Unpacking problem.
you need TcpConn onWriteCompleteCallback to send large data by block .
to look: https://github.com/Qihoo360/evpp/pull/178
you need TcpConn onWriteCompleteCallback to send large data by block .
to look: #178
Thanks, but more request is...how to deal with large block on server...
I am currently using protobuf to serialize network protocols, I am trying to find a simple way to deal with related protocols, regardless of subcontracting, sticky packets ...
The simple request is: send once, recv once....without extra code...
code like:
// client send(msg.SerializeAsString());
// server int OnMessage(const std::string& strBuf) { common_msg msg; msg.ParseFromString(strBuf); }
还是用中文回复你吧。不是很确定我看懂了你的问题。你想问的是怎么用 TcpConn 发送一个巨大的 buffer。 我的建议是永远不要这样做。而是应该在应用协议层，分块的方式发送。
还是用中文回复你吧。不是很确定我看懂了你的问题。你想问的是怎么用 TcpConn 发送一个巨大的 buffer。 我的建议是永远不要这样做。而是应该在应用协议层，分块的方式发送。
我想用TCPConn 发一些可能比较大的文件， 也就是相对上层来说TCP 发到服务器，服务器收到包的时候 好像并不能确保 每次都可以调用Protobuf 的ParseFromString得到对应的包数据，因为存在分包，粘包之类的问题，我在想项目中能不不能把这个做了，也就是 做到A调用一次send， B确保只收到一次OnMessage,(我看了下源码，对于比较大的buf，send的时候好像拆分了）
tcp 是流式的。肯定会有分包或粘包的问题，需要用户自己定义协议，两边用协议解析。 协议定义是用户层的，网络层不会做这个。
顺带 问一句，除了这个是用户层的原因之外，封装成 send once recv once 的模式，有什么坏处或者说不好的地方吗， 因为我觉得这个封装应该是一个很普遍的需求....
tcp 是流式的。肯定会有分包或粘包的问题，需要用户自己定义协议，两边用协议解析。 协议定义是用户层的，网络层不会做这个。
顺带 问一句，除了这个是用户层的原因之外，封装成 send once recv once 的模式，有什么坏处或者说不好的地方吗， 因为我觉得这个封装应该是一个很普遍的需求....
因为做不到。
tcp 是流式的。肯定会有分包或粘包的问题，需要用户自己定义协议，两边用协议解析。 协议定义是用户层的，网络层不会做这个。
顺带 问一句，除了这个是用户层的原因之外，封装成 send once recv once 的模式，有什么坏处或者说不好的地方吗， 因为我觉得这个封装应该是一个很普遍的需求....
因为做不到。
A端口发送的时候将用户的buf 加一个length头， B端在收到消息的时候，根据len再组包 不就是okay的吗，底层怎么封 不都是底层决定的吗...
tcp 是流式的。肯定会有分包或粘包的问题，需要用户自己定义协议，两边用协议解析。 协议定义是用户层的，网络层不会做这个。
顺带 问一句，除了这个是用户层的原因之外，封装成 send once recv once 的模式，有什么坏处或者说不好的地方吗， 因为我觉得这个封装应该是一个很普遍的需求....
因为做不到。
A端口发送的时候将用户的buf 加一个length头， B端在收到消息的时候，根据len再组包 不就是okay的吗，底层怎么封 不都是底层决定的吗...
那这就是你自己的协议嘛，这不是基础网络库应该做的事。还有很多人的协议不是这样的呢？
tcp 是流式的。肯定会有分包或粘包的问题，需要用户自己定义协议，两边用协议解析。 协议定义是用户层的，网络层不会做这个。
顺带 问一句，除了这个是用户层的原因之外，封装成 send once recv once 的模式，有什么坏处或者说不好的地方吗， 因为我觉得这个封装应该是一个很普遍的需求....
因为做不到。
A端口发送的时候将用户的buf 加一个length头， B端在收到消息的时候，根据len再组包 不就是okay的吗，底层怎么封 不都是底层决定的吗...
那这就是你自己的协议嘛，这不是基础网络库应该做的事。还有很多人的协议不是这样的呢？
比如说 什么情况不是这样的... （网络这块不太熟），但是我看来即便不是这样的，对他们也没啥影响啊，他们send一次，收到一次，底层对他们而言都是透明的，这样保证他们send的数据跟收到的数据应该是没有任何影响的啊（加了len可能在网络流量是增加了一点点 但是这个没影响啊）
evpp 可以很方便实现这个功能。onMessage 时，先从 buffer 里peek 一个 int32 出来看下，如果小于 buffer->length() 说明这个包收完了。如果大于 buffer->length() 什么也不用管。它会帮你把没处理的数据保存起来，下次再处理
evpp 可以很方便实现这个功能。onMessage 时，先从 buffer 里peek 一个 int32 出来看下，如果小于 buffer->length() 说明这个包收完了
目前我已经在TCPClient的基础上 封了一层自用，我只是有时候在想 这个东西应该是大多数场景下需要处理的东西，为什么没有一个通用的库做这个