Foutdetectie, correctie CRC ARQ

[Veance]

Ben ik juist dat in de datalinklaag alleen aan foutcorrectie gedaan wordt als het voor wifi of bluetooth is en niet op ethernetaansluitingen omdat de kans op foutieve bits op vaste kabel vrij klein is. Er wordt in dit geval dan alleen aan foutdetectie gedaan en negeren van het frame bij een fout in de checksum (crc)?

Het effectief aanpakken van de fout gebeurt dan in de transportlaag volgens ARQ-protocol. Gebruikt de datalinklaag ook datzelfde protocol? Is dat geen dubbel werk?

De effectieve fout wordt dan niet in een frame, of pakket, maar in een segment van het pakket gevonden. Moet dan daardoor het volledige frame opnieuw opgestuurd worden?

Hoe meer websites ik raadpleeg hoe meer overlapping van informatie ik tegenkom. Op sommige websites zou zelfs de netwerklaag aan foutcontrole/correctie doen.

[ Voor 10% gewijzigd door Veance op 03-11-2022 15:18 ]

[PD2JK]

Op vaste ethernetaansluitingen wordt ook een CRC gedaan, zelfs op de UDP pakketjes.
TCP frames worden opnieuw gestuurd als het niet overkomt bij de ontvanger, bij UDP niet. Maar áls een UDP pakketje overkomt, wordt het op juistheid gecontroleerd.

[Veance]

Ja inderdaad. Bij UDP is de betrouwbaarheid van de informatie niet zo belangrijk. Alleen snelheid en connectie zelf. (Gaming, videostreaming)
Maar UDP is toch een onderdeel van de transportlaag? Ik dacht dat CRC alleen bij de datalinklaag voorkwam?

[ Voor 27% gewijzigd door Veance op 03-11-2022 15:23 ]

[mash_man02]

Let op, het zijn de eindhosts die de data opnieuw moeten versturen en niet zoals met wifi, bluetooth, DLS en docsis iets wat in het netwerk gebeurd.

Binnen ethernet worden frames met een CRC error simpelweg niet geforward tenzijn men gebruik van fragment free of cut trhough switching maar dat is iets wat je vandaag de dag eigenlijk niet meer tegenkomt.

[ Voor 41% gewijzigd door mash_man02 op 03-11-2022 15:23 ]

[Veance]

@mash_man02 wat bedoel je precies met eindhosts?

[mash_man02]

Veance schreef op donderdag 3 november 2022 @ 15:23:
@mash_man02 wat bedoel je precies met eindhosts?

De hosts die in de source en destination ip veld van een pakket genoemd worden. Alle routers en of switches gebruikmakende van ethernet interfaces doen niets anders dan discarten en accounten voor frames waarvan de CRC waarde,ook wel FCS genoemd (frame check sequence) niet klopt.

[ Voor 31% gewijzigd door mash_man02 op 03-11-2022 15:38 ]

[Ben(V)]

Op de datalink layer wordt error check en correct op fysiek nivo uitgevoerd, dat is voor bekabelt hetzelfde als voor wifi.
De data layer zorgt voor een betrouwbare link-to-link verbinding.
Dus bijvoorbeeld tussen de switch en je computer of AP en telefoon

Waar @mash_man02 het over heeft is tcp/udp en dat zit op de transport layer.
Daartussen zit op de network layer nog ip en routing, daar zit ook nog een stukje wifi in.

[Veance]

Kan verkeerd zijn maar ik denk dat het verschil tussen CRC en FCS is dat CRC alleen fouten detecteert en FCS ze ook aanpakt?

[Ben(V)]

CRC en FSC zijn gewoon methoden waarmee packets gecontroleerd kunnen worden, geen van beiden doen iets uit zichzelf.
Als een packet op datalink nivo niet door de crc check komt (ook wel fsc genoemd op dit nivo), dan gooit hij het packet weg en stuurt geen acknowledge, waardoor de andere kant het packet nogmaals gaat verzenden

[hcQd]

Veance schreef op donderdag 3 november 2022 @ 15:43:
Kan verkeerd zijn maar ik denk dat het verschil tussen CRC en FCS is dat CRC alleen fouten detecteert en FCS ze ook aanpakt?

Nee, fcs (frame check sequence) is de ethernet-term voor de gebruikte crc.

Ethernet (t/m 10Gb) gebruikt alleen een crc, wifi gebruikt fec en hertransmissie.

Verder heeft de ip-header zijn eigen 1-complement checksum, evenals de udp- en tcp-payload (optioneel voor udp over ipv4).

Voor wat gedeeltelijk ontvangen pakketten: dit is waarom tcp de segment-grootte beperkt zodat dit normaal niet voorkomt.

[Veance]

Thanks guys. Kan weer wat verder. Maar eerst wat pauseren. Kan even geen afkortingen meer aan.