It's UWAweek 48

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 selected article
Showing 1 of 503 articles.
Currently 2 other people reading this forum.


 UWA week 19 (1st semester, week 10) ↓
SVG not supported

Login to reply

👍?
helpful
4:48pm Thu 9th May, Christopher M.

"Jasper Paterson" <22*3*3*1@s*u*e*t*u*a*e*u*a*> wrote:
> Hi Chris, > > I have seen some examples online and some students who create a new temporary UDP socket whenever a server wants to make a request to another server. The socket is not bound to another port number, it is left to the OS to bind the port to an available port when the sendto() function is called. The socket is closed after the request has been handled. > > I believe this can simplify the logic because the server will receive responses to its requests on a different socket to receiving new requests from other servers. > > Is this allowed / recommended?
Hi Jasper, Yes, this is permitted within our scope, but I can't immediately see any advantage to it. If a datagram is sent from temporary socket, with a randomly assigned port, then the station receiving that datagram doesn't know which station sent it (unless the datagram's payload now includes the name of the sending station). If the original datagram is sent from each station's 'primary' UDP port, then the receiving neighbour knows exactly which neighbouring station sent the request (returned through the recvfrom() call), and so knows who to reply to. If I'm understanding the suggestion correctly, each outstanding query requires a temporary socket being held open until the response arrives (and still needs 'finding' and closing) ??

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