Encounter a doubt when using MR in async-rdma

[mond77]

In studying this library, the following result were encountered. And I was confused about that.
request structure:

client side:

server side:

main:

result:

rpc server started
header size: 28
size: 80, 
Msg { header: RequestHeader { id: 0, type: 0, flags: 0, total_length: 0, file_path_length: 0, meta_data_length: 0, data_length: 0 }, meta_data: [], data: [] }
server side size: 80, 
Msg { header: RequestHeader { id: 0, type: 0, flags: 0, total_length: 6, file_path_length: 0, meta_data_length: 3, data_length: 3 }, meta_data: [1, 2, 3, 4, 5], data: [2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2] }
response: Msg { header: ResponseHeader { id: 0, status: 0, flags: 0, total_length: 0, meta_data_length: 0, data_length: 0 }, meta_data: [1, 2, 3, 4, 5], data: [4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4] }

[mond77]

My doubt is why the Vec data in Msg could be transferred to the opposite end while the 'data' length beyond MR length. And server side received size was still 80, but the data in Msg have gotten passed.

[mond77]

I am developing with this library, do you have an open source developer group chat? Can I participate in it?

[mond77]

Doubt solved. I was careless and didn't pay attention to the localhost communication problem. After switching to remote communication, Segmentation fault is reported.

[GTwhy]

Hi, We can communicate at gitter or discussions

I am developing with this library, do you have an open source developer group chat? Can I participate in it?

[mond77]

In examples/rpc.rs the type of data transferred is String that might misguide users. The data pointed to by String is not actually transferred. Is there a solution for transferring data of variable length in async-rdma?

[GTwhy]

In examples/rpc.rs the type of data transferred is String that might misguide users. The data pointed to by String is not actually transferred. Is there a solution for transferring data of variable length in async-rdma?

Yes you are right! This is a misleading example written in the early stage, we should serialize and deserialize the messages.
Maybe you can make this change if you are interested.

You can use API write_with_imm to write data with a number(length of the data), and do some type conversion unsafely if you want to avoid serialization & deserialization. Here is an example

[mond77]

In examples/rpc.rs the type of data transferred is String that might misguide users. The data pointed to by String is not actually transferred. Is there a solution for transferring data of variable length in async-rdma?

Yes you are right! This is a misleading example written in the early stage, we should serialize and deserialize the messages. Maybe you can make this change if you are interested.

You can use API write_with_imm to write data with a number(length of the data), and do some type conversion unsafely if you want to avoid serialization & deserialization. Here is an example

How could the serialized and deserialized messages of uncertain size be transferred in RDMA? That we even don't know how much memory to allocate. Maybe the simplest example should be like the pr above.

[GTwhy]

Currently, we can only request a fixed size memory region, which cannot adapt well to dynamically changing data structures. Usually, it may be necessary to pre-allocate a larger block of memory and send additional metadata to notify the remote end of the data changes. Thanks for your PR!

[mond77]

Yeah, dynamic data structures need special design to handle. async-rdma gives a good reference for developers who write RDMA programs in rust, and I learned a lot from it and still learning it. Nice job！