1

Suppose you have already an unreliable lossy channel between 2 peers. Which methods can you suggest to transfer data reliably and also without performance loss? Also the underlying protocol is not TCP (which is already reliable). (I used lossy channel to generalize the question.)

( AFAIK, some methods exist like RDT (rfc-908), Go Back-N. )

bjb568
  • 11,089
  • 11
  • 50
  • 71
whoi
  • 3,281
  • 7
  • 36
  • 44
  • Even after your edit stating that you're not using TCP - try to mimic TCP's behaviour on that lossy channel and you'll get a reliable data transfer. – Poni Nov 11 '10 at 10:58
  • Poni, I am trying to figure out other application level protocols. – whoi Nov 11 '10 at 11:01

3 Answers3

1

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Reliable_transmission

Because someone already solved the problem and there is a library (TCP/IP) or ten that does it in every language that exists.

Is this a philosophy question?

Kajetan Abt
  • 1,505
  • 3
  • 15
  • 28
  • +1 simple yet very correct answer. Nothing more than that is needed. I recommend whoi to throughly read the specs and understand why each bit in a TCP header is actually there. You'll get you answer very quickly. – Poni Nov 11 '10 at 10:53
  • Well, yes indeed whole TCP stack can be read and one can rediscover the method. But rather than implementing TCP, as I said there are other methods. What I ask is at application level indeed, not protocol. – whoi Nov 11 '10 at 10:59
  • Fair enough. I would recommend looking for scientific papers on that topic then, in the usual places such as IEEE. There should be an abundance on WLAN technology. – Kajetan Abt Nov 11 '10 at 11:09
  • Whole TCP stack might be an overkill in his situation. – Pavel Urbančík Nov 11 '10 at 11:13
0

As Steve-o said, FEC and as Kdansky suggested Retransmission, are good starting points. The main bottleneck of Retransmission is round-trip times, which causes the delay in receiving a lost packet. However, FEC is a whole different subject and applicable on the packet level. As Steve-o said again, the bottleneck becomes the bandwidth overhead you cause by generating a redundant stream. Although it seems so straightforward, different FEC schemes such as, Parity FEC, Reed-Solomon, Turbo codes, Raptor Q, etc... have different effects on the delay, bandwidth overhead, etc. according to their parameters. (Mostly on the encoding rate that you use to generate the redundant stream)

Erman Doser
  • 116
  • 1
  • 6
0

Without performance loss typically means reducing dependency on the back channel, from the receiver sending ACKs to the sender. This usually means a custom protocol using datagrams and using some form of forward-error-correction (FEC). Note that FEC is a sliding scale that can often be a significant performance penalty because, by definition, you are preemptively sending additional redundant data so that the receiver does not have to ask for it.

http://en.wikipedia.org/wiki/Forward_error_correction http://udt.sourceforge.net/

Steve-o
  • 12,678
  • 2
  • 41
  • 60