Information may be segmented or broken up into smaller chunks or transmission across a physical medium
the maximum transmission unit or empty you of an outgoing interface depends on the physical medium.
As an example they empty you of fust Ethan It is 5400 bytes.
However TZP can theoretically support sixty five thousand four hundred ninety five bytes in a single
packet.
When that is sent to the lower layers of the ozone model that will need to be broken up into fragments
for transmission across the physical medium which for example only supports 50 or 100 bytes.
Data is therefore broken up into smaller chunks and the receiver using TZP will need to put those fragments
back together again.
The maximum segment size or MSA is is the largest amount of data in bytes that TZP is willing to send
in a single segment for best performance.
The MSA is small enough to avoid Arpey fragmentation which can lead to excessive retransmissions if
there's packet loss DCP support something called Maximum segment size and pause.
MT You discovery or Porth maximum transmission unit discovery with the sender and the receiver can automatically
determine what the maximum transmission unit is on a path between them and TZP will only put enough
data into a single packet that fits that empty thus avoiding fragmentation of packets and thus avoiding
the overhead associated with fragmentation and the putting together of the IP fragments off into you
discovery is optional in IP version 4 that has now become mandatory in IP version 6 because of the efficiencies
that it brings to the TZP transmission and the fact that IP version 6 does not support fragmentation
on routers along the path between two hosts UDP does not support this and requires higher level protocols
to sort out the fragments flow control GCP uses end to end flow control to avoid having the sender send
data too quickly for the receiver to receive it and process it reliably.
If the same the transmits data faster than the receiver can handle the receiver will drop the data which
will require a retransmission retransmissions will waste time and network resources which is why most
flow control mechanisms try to maximize the transfer raped while minimizing the requirements to retransmit.
You may as an example have a PC with a powerful you sending data to a handheld PDA which can only process
data at a much lower rate.
The PDA should therefore regulate the data flow so its not overwhelmed in TZP basic flow control is
implemented by acknowledgements from the receiver in receipt of data transmitted EECP uses something
called a sliding window to control the flow of data.
Windowing will allow the receiving computer to advertise how much data is able to receive before transmitting
an acknowledgement to the sending computer.
In each TZP segment the receiver will specify in the receive window field.
The amount of additional received data in bytes that it is willing to buffer for the connection the
sending host can only send up to that amount of data before it Miss White when acknowledgment and window
size update from the receiving host UDP does not implement flow control.
And in a VOIP environment as an example which uses UDP even though there's no physical connection between
two handsets involved in a telephone call the call will stay up and the sender will merrily continue
sending huge amounts of data.
Even though the receiver cannot process the received data UDP relies on Hi-Lo protocols to implement
flow control.
Once again TZP is connection orientated and UDP is connection less TZP will establish the connection
and maintain the connection during the entire transmission.
Once the transmission is complete the session is terminated.
UDP does not set up sessions and will just send the data in the hope that the receiver will receive
it.
Once again TZP implements reliability where every segment transmitted is acknowledged and if the segment
went missing it is retransmitted UDP does not implement reliability.
And once again relies on Hailo protocols to implement any reliability if required in certain cases such
as voice over IP or video transmitted over an IP infrastructure.
Reliability is not required.
There is no point retransmitting last voice packets so a quick comparison between UDP and TZP or a reliable
protocol and a best effort or unreliable protocol TZP once again is connection orientated.
No data is transmitted before a session is established a three way handshake takes place before any
data is transmitted.
There are acknowledgements of data received and sequence numbers to track transmission of data.
UDP on the other hand is connection less and does not track data and does not ensure delivery of data.
TCAP is a sequence of numbers.
UDP does not applications that use TZP include HGP email and FGP applications that use UDP include voice
streaming applications like voice over IP and video streaming applications because of the nature of
VoIP or video.
There is no reason to retransmit in a VOIP environment the talker will be required to repeat what they
said.
If the listener was unable to decipher what was communicated.
If you've ever used Skype at times it may sound like the person speaking is under water or they sound
more like a machine than the person you know speaking.
But you may still be able to understand what they've said and thus even though data went missing the
conversation can continue.
Or if it gets bad enough you would ask the speaker to repeat what they said in a video streaming environment.
You may notice that part of the image is not refresh properly but you're still able to follow what's
happening in the video because of the time sensitive nature of voice and video.
It is pointless retransmitting data and thus TZP is not used in these environments.
UDP is used so UDP is a transport layer protocol.
It resides at layer for when the model it provides applications with access to the network layer all
layer 3 without the overhead over liability mechanisms as discussed.
This is ideal for voice over IP or video applications.
It's connection less where one way datagram the center destination without advance notification to the
destination device.
There is no communication before transmission of data.
The data just arrives at the receiver and it's expected that the receiver handle that data.
UDP is capable of providing very limited error checking the UDP datagram does include an optional check
some value which the receiving device can use to test the integrity of the data the UDP header also
includes a destination port number and if that datagram is directed to an active code on the receiving
device a return message can be transmitted to indicate that that code is unreachable.
I'm going to discuss port numbers in more detail in a moment.
It's a very important concept to understand.
UDP provides best if at delivery.
There is no guarantee that data is delivered packets may be mis directed duplicated or lost on the way
to the destination.
There is no guarantee of receipt of protocols will need to implement reliability if required.
They are also no data recovery features in UDP.
Once again Hiler protocols will need to recover from last corrupted packets.
TFT as an example has a built in mechanism to handle data loss and TFT P using UDP has its own bulled
in sequencing and retransmission mechanisms as it cannot rely on UDP to implement reliability.
The UDP head is very simple.
It has a 16 bit source port number 16 but Port to destination number so the specified the port number
used by the source and a port number used by the destination.
It has a 16 bit ETP length field that specifies the length in bytes of the entire datagram.
In other words the header and the data the minimum length for UDP datagram is 8 bytes because that's
the length of the header.
Theoretically the maximum size is sixty five thousand five hundred thirty five bytes.
But IP version 4 will impose a maximum limit of sixty five thousand five hundred seven bytes.
Optionally a UDP checksum can be used for error checking.
This is optional an IP version 4 but is not optional an IP version 6.