help3002

It's UWAweek 37 (2nd semester, week 7)

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 the 6 articles in this topic

Showing 6 of 503 articles.
Currently no other people reading this forum.

UWA week 18 (1st semester, week 9) ↓

project Unreliable UDP (all 6)

4:03pm Wed 1st May, ANONYMOUS

The project description says that we need to handle any issues which occur with the unreliable UDP. Does this mean that we need to implement some sort of stop and wait protocol to ensure the datagrams are delivered properly?

project Unreliable UDP (all 6)

5:27am Thu 2nd May, Christopher M.

ANONYMOUS wrote:

> The project description says that we need to handle any issues which occur with the unreliable UDP. Does this mean that we need to implement some sort of stop and wait protocol to ensure the datagrams are delivered properly?

You have to address the unreliability, but that doesn't imply that you have to use a stop and wait protocol.

project Unreliable UDP (all 6)

1:52pm Thu 2nd May, ANONYMOUS

"address the unreliability" seems a little vague, it might imply that if a packet is not delivered properly then we just report that and return no value (which addresses it) or it could mean we do something about the packet not being delivered and re-transmit it until it is etc. Is the second approach one we have to take? Do we have to ensure that despite the unreliable nature of UDP the datagram must be transmitted properly?

project Unreliable UDP (all 6)

5:39pm Thu 2nd May, Christopher M.

ANONYMOUS wrote:

> "address the unreliability" seems a little vague, it might imply that if a packet is not delivered properly then we just report that and return no value (which addresses it) or it could mean we do something about the packet not being delivered and re-transmit it until it is etc. > > Is the second approach one we have to take? Do we have to ensure that despite the unreliable nature of UDP the datagram must be transmitted properly?

This is a Level-3 unit, in which the project's requirements are listed, but actual implementation details are not specified. You are not being told what you *have* to do, nor how you *have* to implement your solution. The problem is not open-ended, and there are a number of possible solutions of varying usefulness. As a guide, if you were a user of your application, using a mobile device to post your query, what response/information (on an error) would you prefer to receive? I hope that this helps,

project Unreliable UDP (all 6)

1:44pm Fri 3rd May, Cameron L.

By addressing the unreliability, does that mean we also have to error-check? I'm not sure if " If a datagram arrives, it will be uncorrupted. " is a statement of fact, or a requirement for us to ensure.

project Unreliable UDP (all 6)

6:46am Sun 5th May, Christopher M.

"Cameron Locke" <21*3*2*2@s*u*e*t*u*a*e*u*a*> wrote:

> By addressing the unreliability, does that mean we also have to error-check? I'm not sure if " If a datagram arrives, it will be uncorrupted. " is a statement of fact, or a requirement for us to ensure.

It is a fact, and 'built-in' feature of UDP, that "If a datagram arrives, it will be uncorrupted" - that statement is not a requirement (to add/support) for the project. I strongly suggest that you read from a textbook or the Beej tutorial to get a background understanding of UDP. There's even an online Linux manual entry for it: "This is an implementation of the User Datagram Protocol described in RFC 768. It implements a connectionless, unre- liable datagram packet service. Packets may be reordered or duplicated before they arrive. UDP generates and checks checksums to catch transmission errors."