help3002

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

Showing 2 of 503 articles.
Currently 35 other people reading this forum.

UWA week 19 (1st semester, week 10) ↓

Using temp socket for udp request (both)

12:33pm Thu 9th May, Jasper P.

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? Cheers, Jasper

Using temp socket for udp request (both)

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) ??