5.5. 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.5.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%�
Fault1:5.5.2. Lost PacketwithinData 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.
Fault2:5.5.3. Lost PacketattheEndoftheData Stream
In case of a fault at the end of the data stream, the application will wait for incoming pack-
ets for a predened time. When this time has elapsed, the resend request is triggered and
the "lost" packets will be resent.
◄Figure43
Data stream without
damaged or lost pack-
ets.
◄Figure44
Resending lost packets
within the data stream.
To Next Page
Loading...
