[ee122] MNL vs. UDP sendto()

[Lisa Fowler]

Discussions regarding the requirements of MNL have been regular on the
list and featured in the FAQ.  I have also answered this question a
few times in office hours.  I'm sorry that these resources were
unavailable to you, but they have been provided.

HOW MNL WORKS:

Sender listens on 5670.    Receiver listens on 7890.
MNL(sender) listens on 12345.     MNL(receiver) listens on 54321.

Sender sends to Receiver:7890 via MNL_sendto.  (Src= sender:5670, Dst=
receiver:7890)

MNL_sendto rewrites the 7890 with 12345, so that MNL(sender)
intercepts the packet.  (Src= sender:5670, Dst= sender:12345)

MNL(sender) then fiddles with the packet, possibly dropping it, and
rewrites the destination to how it was before -- due to not being
root, the source port has to change:  (Src= sender:12346, Dst=
receiver:7890)

Receiver receives (Src= sender:12346, Dst= receiver:7890)

To respond, Receiver must send all responses to (Src= receiver:7890,
Dst= sender:5670), which it could save as a global state variable
regarding its "connected host"

Thus, Receiver sends the responses to (Src= receiver:7890, Dst= sender:5670)

Which gets intercepted via MNL(receiver)  (Src= receiver:7890, Dest=
receiver:54321)
And which gets rewritten by MNL(receiver)  (Src= receiver:54322, Dest=
sender:5670)


IF you do not handle byte ordering properly, you will have problems.
If you don't recompile MNL on the correct servers and somehow are
using an old MNLDaemon.sock, you'll have problems.  If you're not
using c199 and sphere, you might have NAT or firewall issues to
contend with.  If you are testing to see if incoming packets are from
the correct host without dealing with this port-rewrite issue, you may
have dropped your own packet.

If you are still having problems, you may contact me directly.  Just
about every "MNL bug" that I have been debugging with you has been
unique and centered on your code and your unique implementation.

-Lisa



On Dec 11, 2007 1:14 AM, Kristian Lyngbaek
<kristianlyngbaek at berkeley.edu> wrote:
> We had a fully functional ready to submit program using UDP sendto() (well
> before submission deadline i might add).
>
> We are under the impression that MNL sendto() is supposed to be a
> transparent function such that we can replace all of our UDP sendto()s with
> MNL sendto()s.
>
> This is not the case.
>
> In an attempt to prepare for the HTTP client/server early on, our
> implementation involves a listening port on the receiver that sets up pairs
> of sockets on either side.  (one for outgoing, one for incoming data - these
> were meant to be used for data transfer in HTTP transactions)
>
> We connected the sockets on either end, and our UDP sendto() calls look like
> this:
>
>    sendto(node->out_fd, &s_header, S_HSIZE, 0, NULL, sizeof blankAddr);
>
> Our MNL sendto() calls look like this:
>
>   MNL_sendto(node->out_fd, &s_header, S_HSIZE, 0, serv_addr, length,
> node->seqNumber, 0, S_HSIZE, &error);
>
>
> (serv_addr is allready struct sockaddr pointer, error is a local variable,
> etc. (basically our arguments are valid))
>
> When we replaced our UDP sends with MNL sends, the MNL daemons said that the
> packets were getting sent to the appropriate sockets, but in reality the
> packets were not making it.
> It seemed that MNL sentto() only worked between the initial sender socket
> and receiver listening port. As soon as the receiver handed over the job to
> the other specially created sockets/ports MNL sentto() stopped working,
> although UDP sendto() does.
>
> We were wondering if MNL sendto() can only support 1 connection - Or
> transfer between only 2 sockets.  As in if you send from one socket to
> another.  And then from the same socket to a DIFFERENT one, will MNL fail?
> because in our case it sure seems like it does.
>
> Any ideas?
>
> Thanks.
> _______________________________________________
> ee122 mailing list
> ee122 at mailman.ICSI.Berkeley.EDU
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/ee122
>
>