It's UWAweek 47

help3002

This forum is provided to promote discussion amongst students enrolled in CITS3002 Computer Networks.

Please consider offering answers and suggestions to help other students! And if you fix a problem by following a suggestion here, it would be great if other interested students could see a short "Great, fixed it!"  followup message. How do I ask a good question?

Displaying 13 tagged articles
Showing 13 of 503 articles.
Currently 55 other people reading this forum.


 UWA week 22 (1st semester, study break) ↓
SVG not supported 2:59pm Tue 28th May, ANONYMOUS

Nevermind, not sure what was happening before, just downloaded it then.


SVG not supported 8:10pm Mon 27th May, ANONYMOUS

Hi there, Just looking to download the lecture 10 PDF but doesn't seem to download when I click the icon there, giving me a 404 Not Found.


 UWA week 20 (1st semester, week 11) ↓
SVG not supported 7:17pm Sat 18th May, William R.

Have you tried cits3002 schedule?


SVG not supported 5:42pm Sat 18th May, ANONYMOUS

Has the week 11 lecture been uploaded? I can't seem to find it anywhere...


 UWA week 18 (1st semester, week 9) ↓
SVG not supported 8:29am Sun 5th May, Christopher M.

ANONYMOUS wrote Yes (there's a lot of overlap, here, with what we discussed in Tutorial 4) It's very likely that your home router will support private addresses of the form 192.168.x.y (a widely used default), and that your neighbour's router will use...


SVG not supported 9:07pm Sat 4th May, ANONYMOUS

Hello, I was just reviewing lecture 7 (and internet sources) and was a little confused about what seems to be the shared purpose role of private IPs and mac addresses. From what I understand, public IP's are globally unique to allow for accurate send...


 UWA week 15 (1st semester, week 6) ↓
SVG not supported 5:37am Tue 9th Apr, Christopher M.

ANONYMOUS wrote In practice the situation is blurred because the PL and DLL are combined in a Media Access Control (MAC) Layer, such as a single Ethernet interface card. If taken too literally - that the PL is just the wire itself, the scene where e...


SVG not supported 5:20am Tue 9th Apr, Christopher M.

ANONYMOUS wrote Discarding DATA will result in it, eventually, being re-transmitted, but not for the longest (anticipated) time. During the period of time, we hope that the congestion will 'die' down while the sender waits for the ACK (which will now...


SVG not supported 10:36pm Mon 8th Apr, ANONYMOUS

Lecture 2 states " RX Monitors (only detects) transmission errors" as a responsibility of the physical layer. How does the physical layer detect errors? Are detection techniques such as hamming, parity, crc etc not a function of the DLL? Could I als...


SVG not supported 12:21pm Mon 8th Apr, ANONYMOUS

When choosing the best candidates for removal via load shedding, why is it that we discard DATA instead of ACKs, as per the lecture notes? Wouldn't it be easier to retransmit just a single bit for an ACK or is it to do with the idea that the ACK is ne...


SVG not supported 11:55am Mon 8th Apr, Christopher M.

ANONYMOUS wrote Hello, yes, you are correct. I have corrected the last sentence on each of page 20 and page 21. (There seems to have been some poor cut-and-paste going on there - I wonder for how many years it went un-noticed...?) Thanks.


 UWA week 14 (1st semester, non-teaching week) ↓
SVG not supported 4:06pm Sun 7th Apr, ANONYMOUS

I think the statement is pointing out that even though an application (a node) is generating bursty traffic. Because this traffic is being fed into the leaky bucket algorithm, it doesn't saturate the network as the leaky bucket only permits a specifi...


SVG not supported 12:00pm Sat 6th Apr, ANONYMOUS

Hi, i am hoping to get some clarification on this statement from pg. 20 of Wk. 5 lecture "The leaky bucket algorithm enables an application to generate bursty traffic (high volume, for a short period) without saturating the network". I would've though...

The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Written by [email protected]
Powered by history
Feedback always welcome - it makes our software better!
Last modified  8:08AM Aug 25 2024
Privacy policy