- Posts: 6
- Thank you received: 0
Local and metropolitan networks
15 years 10 months ago #29361
by longgone
Local and metropolitan networks was created by longgone
An asynchronous device, such as a teletype, transmiits characters one at atime with unpredictable delays between characters. What problems, If any, do you forsee if such a device is connected to a LAN and allowed to transmit at will(subject to gaining access to the medium)? How might such problems be solved?
Need help with this one!!!
Thank you
longgone
Need help with this one!!!
Thank you
longgone
15 years 10 months ago #29374
by S0lo
Studying CCNP...
Ammar Muqaddas
Forum Moderator
www.firewall.cx
Replied by S0lo on topic Re: Local and metropolitan networks
Not sure I got your question. Once a device is connected physically (and correctly) to a LAN, it will have access to the physical medium, but not necessarily to the network resources. Can you explain more?
Studying CCNP...
Ammar Muqaddas
Forum Moderator
www.firewall.cx
15 years 10 months ago #29384
by longgone
Replied by longgone on topic Re: Local and metropolitan networks
I guessing that what is being asked is that a teletype poses some kind of problem depending on the topology of the network. If it does what kind and how do you resolve it?
15 years 10 months ago #29388
by S0lo
Studying CCNP...
Ammar Muqaddas
Forum Moderator
www.firewall.cx
Replied by S0lo on topic Re: Local and metropolitan networks
I'll assume that Ethernet LAN is used. There are two cases.
1. If the LAN is connected using a Hub.
For basics, Ethernet LAN uses CSMA/CD (Carrier sense multiple access with collision detection). Two terms here to understand.
"Carrier Sense" means that a transmitting PC listens to the medium before trying to send data signals. It tries to detect the presence of a data signal from another PC before attempting to transmit. If a signal is sensed, the PC waits for the transmission in progress to finish before initiating its own transmission.
For this, it means if the teletype transmits, all other PCs will wait for it to finish before they try to send. If the teletype transmits too frequently, this obviously can slow down things.
"Collision Detection" means that (in the case that two PC transmit at nearly the same time) a transmitting PC that detects another signal while transmitting it's own signal, stops transmitting that signal, then it transmits a jam signal (to let all other PC know that there is a collision), and then waits for a random time interval (known as "backoff delay") before trying to send that data signal again.
Obviously the teletype does not know these rules, it will not wait for other PC signals to finish, it will send when ever it wants. Hence it can cause more collisions making LAN PCs fall frequently in the backoff delay period (not sending data).
Overall, I expect a slow down in network performance
2. If the LAN is connected using a switch
A switched LAN is a collision free LAN. So the teletype will not have any bad effect. However, I'm not sure what the switch's behavior would be in response to the teletype signals.
Thats as far as I understand it.
1. If the LAN is connected using a Hub.
For basics, Ethernet LAN uses CSMA/CD (Carrier sense multiple access with collision detection). Two terms here to understand.
"Carrier Sense" means that a transmitting PC listens to the medium before trying to send data signals. It tries to detect the presence of a data signal from another PC before attempting to transmit. If a signal is sensed, the PC waits for the transmission in progress to finish before initiating its own transmission.
For this, it means if the teletype transmits, all other PCs will wait for it to finish before they try to send. If the teletype transmits too frequently, this obviously can slow down things.
"Collision Detection" means that (in the case that two PC transmit at nearly the same time) a transmitting PC that detects another signal while transmitting it's own signal, stops transmitting that signal, then it transmits a jam signal (to let all other PC know that there is a collision), and then waits for a random time interval (known as "backoff delay") before trying to send that data signal again.
Obviously the teletype does not know these rules, it will not wait for other PC signals to finish, it will send when ever it wants. Hence it can cause more collisions making LAN PCs fall frequently in the backoff delay period (not sending data).
Overall, I expect a slow down in network performance
2. If the LAN is connected using a switch
A switched LAN is a collision free LAN. So the teletype will not have any bad effect. However, I'm not sure what the switch's behavior would be in response to the teletype signals.
Thats as far as I understand it.
Studying CCNP...
Ammar Muqaddas
Forum Moderator
www.firewall.cx
15 years 10 months ago #29389
by longgone
Replied by longgone on topic Re: Local and metropolitan networks
Thanks S0lo, this is very helpful, this is a great forum, keep up the good work.
15 years 10 months ago #29395
by TheBishop
Replied by TheBishop on topic Re: Local and metropolitan networks
There's a possibly similar-but-different way of looking at this too, depending on how pedantic you want to be with the wording of the question. Specifically, with the comment 'subject to access to the medium'. I read that as saying that they are accepting there will be issues (around CSMA/CD) relating to a device like this accessing a LAN but that they are letting you ignore them.
Given that, what remains is a slightly different set of issues. A teleprinter device like this is a mechanical, brainless thing that will just send each character when the key is pressed regardless of whether the receiving end is ready for it or not and with no means of confirming that the receiving end has even received it (a sort of mechanical equivalent of UDP). The drawbacks therefore revolve around there being no guaranteed delivery and no error checking, and we could mitigate them by, say, having the device transmit into a memory of some sort which could then send to the other end in a more controllable and robust way
Given that, what remains is a slightly different set of issues. A teleprinter device like this is a mechanical, brainless thing that will just send each character when the key is pressed regardless of whether the receiving end is ready for it or not and with no means of confirming that the receiving end has even received it (a sort of mechanical equivalent of UDP). The drawbacks therefore revolve around there being no guaranteed delivery and no error checking, and we could mitigate them by, say, having the device transmit into a memory of some sort which could then send to the other end in a more controllable and robust way
Time to create page: 0.132 seconds