You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, tokio_kcp can't communicate with kcp-go because: beside kcp, kcp-go also adds other features that change its protocol header, e.g. crypto, crc, fec. It should be emphasized that these features are kcp-go specific.
Though, being compatible with kcp-go might be not the goal of tokio_kcp, I believe adding the ability for users to modify the datagram to support their own headers makes it possbile. It would also extend the potential usage of tokio_kcp.
The text was updated successfully, but these errors were encountered:
For example, define a trait like below for users to impl and use them in tokio_kcp:
pubtraitProtocolExtender{// tokio_kcp needs this beforehand when caculate mtufnheader_len() -> u16;// When receive udp datagram, firstly call recv() to modify the data, then pass it to kcp.fnrecv(&mutself,data:Vec<u8>) -> Vec<u8>;// When kcp tries to send data, firstly call send() to modify the data, then pass it to udp socket.fnsend(&mutself,data:Vec<u8>) -> Vec<u8>;}
Firstly, thanks for the great repository!
Currently, tokio_kcp can't communicate with kcp-go because: beside kcp, kcp-go also adds other features that change its protocol header, e.g. crypto, crc, fec. It should be emphasized that these features are kcp-go specific.
Though, being compatible with kcp-go might be not the goal of tokio_kcp, I believe adding the ability for users to modify the datagram to support their own headers makes it possbile. It would also extend the potential usage of tokio_kcp.
The text was updated successfully, but these errors were encountered: