republican-creole
Search:  

 
 
   All ForumsHot TopicsGallery






how-to block ads


 
Forums » Up and Running » Security » Security » Network error handling.
Search Topic:
Uniqs:
325
Share Topic:
RSS topic:
toggle:
flat / full
normal / watch
Posting:
Post a:
Post a:
One Trillion Dollars and then some »
« Help, Redirecthost and Svhost problem  
AuthorAll Replies


tempnexus
Premium
join:1999-08-11
Boston, MA

Network error handling.

OK I got a question this seems like a standard practice in networking but I cant find any reference to back up my assumption. So if anyone could help me find a reference that teaches:
"Once the Error code (or errors)are received over the network, the Ethernet link (card) waits a specific period of time, and if the errors are still present after the specific amount of time, it disables the ethernet port (in transmission direction) (or shuts it down or redirect it etc)" next "Enables the ethernet card/port/transmission once the error codes (Errors) no longer are being received, but before it does that the card waits a specific amount of time before re-enbling the tranmission just to make sure that the error free state is not transient).

Thanks a bunch, want to win an argument by telling my friend that what he is saying is soo obvious that it has been done before...except I can't find any reference to support my statement.

Mods: If this is inapropriate forum them could you please move it to one that fits this topic the best. Thank you so much.

dave
Premium,MVM
join:2000-05-04
not in ohio
At present, it's too vague to comment on.

E.g., what does "error code ... received" mean?

What protocol are we talking about?


tempnexus
Premium
join:1999-08-11
Boston, MA
error code = erronous packets, missed packets, crc failed etc.

TCP or Ethernet over Sonet, Sonet, etc.

dave
Premium,MVM
join:2000-05-04
not in ohio
·Verizon Online DSL
·Verizon FIOS

reply to tempnexus
Oh, nothing that was actually received, then - you mean that the adapter reported an error?

So the theory is that the NIC stops transmitting on error condition, and restarts transmitting when the error condition has cleared. And the allegedly novel idea is that the NIC should 'wait a bit longer' just to make sure the error condition has really cleared?

You're right, it doesn't sound too earth-shattering.

I think the crux of the matter hinges on how the state 'error condition has cleared' is defined? You may find that the definition includes some time consideration -- e.g., 'such and such a signal has remained clear for at least X microsecs'.

I have no reference for you, though.
Forums » Up and Running » Security » SecurityOne Trillion Dollars and then some »
« Help, Redirecthost and Svhost problem  


Monday, 09-Nov 17:19:33 Terms of Use | Privacy Policy | Hosting by www.nac.net - DSL,Hosting & Co-lo | feedback | contact
over 10 years online! © 1999-2009 dslreports.com.
page compression OFF
Most commented news this week
· [61] VoIP Over 3G Still Not Working For iPhone
· [40] Verizon Keeps Swinging At AT&T
· [26] Bill Would Force ISPs To Block Financial Scams
· [14] Mediacom Hints At 50, 100 Mbps Speeds
· [10] Clearwire To Get Another $1.5 Billion
· [9] 15 States Have Now Gotten Broadband Mapping Money
· [4] AT&T Launching New 7.2 Mbps 3G Modem
Most people now reading
· Google Has Acquired Gizmo5 [VOIP Tech Chat]
· Framed for child porn 151; by a PC virus [Security]
· My cat is reluctant to exercise. [General Questions]
· How in the world am I going to get into college? [General Questions]
· Divorce advice... [General Questions]
· Windows 7 boot manager editing questions [Microsoft Help]
· Telus supports CRTC's NN and UBB [TekSavvy]
· 60 Minutes piece on cyber security last night [Security]
· 3.x Feral Druid - Bear Tanking Guide [World of Warcraft]
· [ PVP] 3.2 DK PvP D/W Spec... [World of Warcraft]