Baumer TXG - 5.7 Packet Resend; 5.7.2 Fault 1: Lost Packet within Data Stream

66
5.7 PacketResend
Due to the fact, that the GigE Vision
®
standard stipulates using a UDP - a stateless user
datagram protocol - for data transfer, a mechanism for saving the "lost" data needs to be
employed.
Here, a resend request is initiated if one or more packets are damaged during transfer
and - due to an incorrect checksum - rejected afterwards.
On this topic one must distinguish between three cases:
NormalCase5.7.1
In the case of unproblematic data transfer, all packets are transferred in their correct order
from the camera to the PC. The probability of this happening is more then 99%.
Fault1:5.7.2 LostPacketwithinDataStream
If one or more packets are lost within the data stream, this is detected by the fact, that
packet number n is not followed by packet number (n+1). In this case the application
sends a resend request (A). Following this request, the camera sends the next packet and
then resends (B) the lost packet.
In our example packet no. 3 is lost. This fault is detected on packet no. 4, and the re-
send request triggered. Then the camera sends packet no. 5, followed by resending
packet no. 3.
Fault2:5.7.3 LostPacketattheEndoftheDataStream
In case of a fault at the end of the data stream, the application will wait for incoming pack-
ets for a predened time. When this time has elapsed, the resend request is triggered and
the "lost" packets will be resent.
Figure75►
Data stream without
damaged or lost pack-
ets.
Figure76►
Resending lost packets
within the data stream.