[Drbd-dev] Protocol C

[raulhp]

El 2014-05-28 20:36, Lars Ellenberg escribió:
> On Wed, May 28, 2014 at 05:25:28PM +0200, raulhp wrote:
>>
>>
>> El 2014-05-28 14:49, Lars Ellenberg escribió:
>> >On Wed, May 28, 2014 at 02:32:05PM +0200, raulhp wrote:
>> >>Hi Lars,
>> >>
>> >>Thanks so much, I focus only the replication link, the first 
>> develop
>> >>is implement the replication to n servers with reliable multicast,
>> >>ensuring the write in the remote disk.
>> >>
>> >>Can you explain me this ? Where? ---> You would need to find the
>> >>"relevant" requests on the resource->transfer_log()
>> >
>> >See in drbd_send_and_submit(), and helpers, e.g.
>> >drbd_process_write_request,
>> >where the requests are put on the transfer log in incoming order.
>> >
>> >The drbd sender threads (wait_for_sender_todo, process_one_request)
>> >find them there, and send them.
>> >
>> >The drbd asender thread receives the acks (or, in your case
>> >the retransmit requests), needs to validate thes acks (or neg acks,
>> >or retrsnamit requests), and change the state of the respective
>> >request
>> >object.
>> >
>> >That's what happens in got_BlockAck and friends.
>> All this it´s ok!
>>
>> >Now you want to implement some mcast.
>> >I don't know what information you envison to have,
>> >what would make you ask for retransmit,
>> >what exactly you would ask for,
>> >what information you could use in your got_retransmit_request
>> >function.
>> >
>> I want to implement a mcast with NACK, where the receiver send NACK
>> message to the sender when the receiver detects a loss packet, and
>> the sender send the packet in question, with this is possible
>> guarantee all writes in the remote node and reduce the traffic in
>> the network.
>>
>> >But the drbd_request will stay linked on the resource->transfer_log
>> >until it is "acked", or "cleaned up" due to connection loss.
>>
>> It´s ok
>>
>> >Depending on the information you have in that restransmit request,
>> >you will be able to find the relevant requests on that transfer 
>> log.
>> >I don't know what information you have, so I cannot tell how to 
>> best
>> >find them.
>> >
>> >Non-relevant are:
>> >  those that have not been sent yet (to that peer)
>> >  those that have already been ACKed (by that peer)
>> >Which means that relevant are
>> >  those that have been sent, but not acked,
>> >  and fall in whatever "range" you request to be restransmitted.
>> This is ok, but with Multicast communication is necesary to use UDP
>> Protocol with Reliability.
>
> Of course.
> So?
>
> We already have a "NACK", in the DRBD protocol,
> which carries the meaning "failed to serve this request"
> (the IO subsystem of the peer reported failure).

The NACK in te DRBD protocol is used in Protocol C? or?

> Lets not overload the term "nack",
> and use the term "retransmit request",
> because that is basically what a "nack"
> in any reliable multicast protocol is supposed to trigger:
> retransmit of not received messages.

Yes, the term "NACK" works well

> The receiver notices (by timeouts and sequence numbers and other
> conditions) that it missed messages, and sends back that it'd like
> to please have "these" messages again.
>
> Maybe it is useful to have both:
> the "multicast" channel,
> and still the tcp mesh channels for retransmits,
> and maybe for read requests or other directed messages.
> (just an idea)

The idea is to use multicast channel to send the data replication and 
TCP mesh channels for retransmits and keep the connection resource , or 
if the packet loss is large using the multicast channel.

> The node that originally sent the requests
> now sees this retransmit request,
> and needs to process it.
>
> To do that, it needs to find the original request,
> and resend it.
>
> Luckily we have all requests
>   * on the transfer log
>      (struct drbd_resource: transfer_log)
>   * and in the interval tree
>      (see validate_req_change_req_state
>       and find_request).
>
> So based on what information you put in your retransmit request
> you should be able to find the original either on the transfer log
> or in the interval tree, and resend it.

It´s OK

> Am I misunderstanding your question?
You understand my question :-) only y want to understand how to use 
existing code of ACK for multicast