Re: CSMA/CD

["K sPecial" <xzziroz () linuxmail org>]

Also take into recognition that there is a difference in length between what's called a "short" jam and a "long" jam. 
The difference is how far along the line from the sending host that the jam happens, usualy past are worst since if the 
line is too long and Machine A sends a message to machine B, the interval to wait is 0.9, if the line is long enough 
where as they had both waited that long And machine A had sent the message to B, B could send a message (legaly) that 
had followed the rule of waiting the .9, and still have a collision because of the ammount of time it had taken for 
machine A's message to get to machine B. This is a long collision and the problem here is that if its very long in some 
cases Machine A can go back into listen mode and not know there was ever a collision if it has transmitted all of it's 
data before the JAM signal propogates to himself. NICS only recognize a JAM when they are in send mode.

--K-sPecial

----- Original Message -----
From: Ansgar Wiechers <bugtraq () planetcobalt net>
Date: Fri, 22 Aug 2003 10:30:55 +0200
To: Security-basics () securityfocus com
Subject: Re: CSMA/CD

> On 2003-08-21 David Gillett wrote:
> > Before a CSMA/CD device transmits, it listens to hear that the wire is
> > clear.  (If it isn't, it waits for a while and listens again.)
> > There's a potential race condition where two (or more!) devices
> > listen, find that the wire is clear, and both decide to transmit. Part
> > of resolving this race condition is for each frame transmission to
> > start with a "pad" of known filler.
>
> I may be wrong here, but AFAIK this is not the way padding works.
>
> Say you have two stations located at the two furthermost ends of the
> ether. If one station starts sending, the signal takes some time to
> propagate (since it travels with approximately 0,6 light speed only).
> Now assume the other station starts sending right before the signal
> reaches its port. In the next moment it will receive the first signal,
> detect a collision (this is implemented in hardware AFAIK - something
> like an XOR gate between input and output - since software would not be
> responsive enough to accomplish this task) and a jam signal is sent.
> This station is aware of the collision now, but the first station still
> is not! Only when it receives the signal the second box sent before
> finishing its own transmission, it will be able to detect that a
> collision occured. This is accomplished by defining the minimum frame
> size (64 byte) large enough to make sure a station keeps sending at
> least the time a signal needs to cover twice the maximum segment size
> ("there and back again").
>
> So where does pad fit in here? Unfortunately, en empty eternet frame
> (headers only) is smaller than 64 byte (just 18 byte: destination
> address, source address, type, FCS), so every frame smaller than 64 byte
> is filled up with zeroes (or maybe even garbage, I'm not sure) to have
> the required minimum size. This fillup is called pad.
>
> Regards
> Ansgar Wiechers
>
> ---------------------------------------------------------------------------
> ----------------------------------------------------------------------------

-- 
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze

---------------------------------------------------------------------------
----------------------------------------------------------------------------