Well the pipes vs addressing thing is a bit confusing, so I like to look at it like this:
const uint64_t addresses[2] = { 0xF0F0F0F0E1LL, 0xF0F0F0F0D2LL };
radio.openWritingPipe(addresses[0]);
radio.openReadingPipe(1,addresses[1]);
Then, to answer your question, yes. As long as the transmitter and receiver are using opposite addresses, it should work fine. The pipe numbers aren't always that important, mainly the addresses.
And i thing you have make you're own rf24 library ... write ? i will do a better read smiley
Yup, I've created a faster/more efficient fork of the RF24/RF24Network libs that support a wider range of hardware and functionality, mainly to improve my audio library and its capabilities.
if the above it is correct how can i collect the data in Rx side ?
The memcpy looks ok, except the second one should use length 32 instead of 64. In this case you will probably want to use some sort of simple protocol to manage the payloads and re-assembly.
For example, the transmitter could number the payloads by modifying the first or last byte of the payload, so the receiver knows if it has received all of the payloads in the correct sequence. Or you could send a 'start payload' telling the receiver to expect three payloads within a certain timeframe, and indicate that they will need to be re-assembled. I've included an example of the latter method in my library fork: http://tmrh20.github.io/RF24/TransferTimeouts_8ino-example.html , but the write method needs to be changed to work with any of the other libs. *Edit to add: It might be easiest to also spread out the data being sent so all the payloads are the same size. Otherwise that needs to be accounted for on the receiving end.
Then on the receiving end, its just a matter of confirming successful transfer, then reversing the operation, and writing the payload data into a 68 byte array, which you could do by reversing your memcpy code, or with a for loop.