[ee122] gathering info with random unused ports (sin_port == 0)

Lisa Fowler fowler at eecs.berkeley.edu
Sun Nov 25 23:36:19 PST 2007


On Nov 25, 2007 11:16 PM,  <vern at eecs.berkeley.edu> wrote:
> > From there, though, how do I figure out what port the kernel chose? Did it
> > overwrite the value? Is there a function analogous to getpeername() where
> > the struct gets filled in with info?
>
> Yes, see getsockname().

Since with MNL, you need to know the port ahead of time, you might
want to use the technique found in TestSend.c (in MNL) and bind the
sender's socket to a random port number in advance of doing a sendto.

> > I need to advertise the second (incoming on the initiator side) socket to
> > the reciever if he is intending to send things back, but I can't find where
> > to get my random port number for the socket I'm using.
>
> Keep in mind that Project 2 no longer requires establishing bidirectional
> communication, so you don't in fact need to set up this sort of rendezvous.

This is correct in so far as the project specs are asking, because
technically, you are able to send ACKs right back to the sockaddr that
you got from recvfrom() without having to build another channel of
communication.

However, if you want to use MNL, you *do* need to share a port number.
 Note that this is a separate issue!

e.g.
Sender creates a UDP packet with ports:  src 1 dst 500
Sender uses MNL_sendto instead of sendto()
MNL re-wraps the packet, and changes UDP ports to:  src 90 dst 500
Client reads the sockaddr that it got from recvfrom and sees a sin_port of 90  !

So to send a packet *back* to the Sender (and not MNL), you have to
include a reply-to (or source) port in your packet or custom header
somehow so that the receiver will be able to rewrite the dst port to
1.

Yes?

Let me know if that doesn't make sense.  Try it out if you get a chance.

Lisa


More information about the ee122 mailing list