CareerCup

I think this is a good solution:

Your channel can TX 1Gbps that is about 1*10^9 bits.
The guy is talking about turnaround time (or round-trip time RTT) so I guess he wants a protocol where sent data must be acknowledged.

So how much data does a server need to store while waiting for and ACK? all the data that has been sent before the arrival of an ACK!

buff = 1Gbps * 500usec. = 1024*Mbps * 5*10^-4 sec = 0.05Mb = 51.2KB

Now we need one buff to store the data that we sent and one to store the data that
we are sending so probably we need tot_buff = 2*buff

The protocol would require a packet ID, so that:

Send_packet: { void* data }
Response_packet: {bool ack }

The protocol should not use and ID because the ACK arrives always on time to be sure
that the ACK refers to the previously sent data frame.

I think this is a good solution:

Your channel can TX 1Gbps that is about 1*10^9 bits.
The guy is talking about turnaround time (or round-trip time RTT) so I guess he wants a protocol where sent data must be acknowledged.

So how much data does a server need to store while waiting for and ACK? all the data that has been sent before the arrival of an ACK!

buff = 1Gbps * 500usec. = 1024*Mbps * 5*10^-4 sec = 0.05Mb = 51.2KB

Now we need one buff to store the data that we sent and one to store the data that
we are sending so probably we need tot_buff = 2*buff

The protocol would require a packet ID, so that:

Send_packet: { void* data }
Response_packet: {bool ack }

The protocol should not use and ID because the ACK arrives always on time to be sure
that the ACK refers to the previously sent data frame.