[Drbd-dev] Protocol C

[Lars Ellenberg]

On Thu, May 29, 2014 at 12:45:32PM +0200, raulhp wrote:
> 
> 
> 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?

Always.

You do realize that there is
  * the transport protocol (TCP)
  * the DRBD protocol

*BOTH*
tcp and DRBD-protocol have "acks" and "nacks",
and they mean different things.

DRBD ACKs (actually: P_WRITE_ACK in protocol C, for other variants see
enum drbd_packet) mean that the corresponding request has been completed
by the remote disk.

DRBD NACKs (P_NEG_ACK) mean that the remote disk was not able to process
the request, or tried and failed (IO-error).

On the TCP level, the TCP acks and stuff has the TCP meaning.

With a "reliable multicast transport" for DRBD,
you will need transport specific messages.
the DRBD protocol on top of that won't care much,
as long as it eventually gets the P_WRITE_ACK
or P_NEG_ACK.

> >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

I just tried to explain why the term NACK does NOT work,
and why I suggest to use retransmit request instead :-/

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

I don't think it works that way.

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.