[Lab 3] Part 4: Sending multicast messages

[Lab 3] Part 4: Sending multicast messages

par Kilian Schneiter,
Nombre de réponses : 4

Hello,

I have an issue in the part 4 of the lab 3, when we are trying to send multicast messages. When I run both my receiver.py and my sender.py in the VM, I'm able to see the input message (along with the SCIPER) I send in the receiver's terminal.

However, when I submit it for grading on the grading system, I get 1/5 and all the tests that fail tell me that they can't find the message beginning with the chosen SCIPER. In the logs, I can see that all tests result in an "OSError: [Errno 98] Address already in use", despite having clearly set "sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)" before binding the socket. Do someone know here it may come from?

Thanks!

En réponse à Kilian Schneiter

[Lab 3] Part 4: Sending multicast messages

par Gaiëtan Renault,
Hello Killian,

You should not set those socket options ("sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)") nor bind the SENDER socket.

Hope this helps,
Gaiëtan.
En réponse à Gaiëtan Renault

Re: [Lab 3] Part 4: Sending multicast messages

par Jérôme Lou Jonas Amiguet,

Hello Gaiëtan,

Why shouldn't we bind the sender socket? Is this generally the case, or just because of this setup?

Also, how can we set the port if we never bind it?

Cheers,
Jerome

En réponse à Jérôme Lou Jonas Amiguet

Re: [Lab 3] Part 4: Sending multicast messages

par Gaiëtan Renault,
Hello,

> Because of the setup you are given :
•  group is the multicast group address ON which to SEND the message (i.e group is destination multicast group addr.).
•  port is the port number ON which to SEND (i.e port is destination port number).

The local socket of the sender should thus not be bound to this group nor this port (as otherwise it will change source addr./port). Sender socket could send from whatever address/port. In a general manner, when a socket is used to send data, we let the OS assign to it source addr. and port value.

> You thus only make use of group & port when sending your data.

Hope it's now clear,
Gaiëtan.
En réponse à Gaiëtan Renault

[Lab 3] Part 4: Sending multicast messages

par Ludovic Thomas,
Hello, to complete on Gaiëtan's anwser:

What does the SO_REUSEADRR option do ?

When you create a socket, say s1, it is bound to an ip/port and will therefore *receive* the packets with this *destination* ip/port and with the associated protocol (UDP/TCP) (if it's a connected TCP socket it will only receive the packets coming also from the connected remote end). As Gaiëtan explained, this IP/port is either attributed by default by the OS or by the bind() if you want your application to receive on a specific port. If another socket, say s2 from another program, binds to the same ip/port, then it will also receive the packets with this destination ip/port. This represents a risk for confidentiality: a malicious program could read the data intended to another program! This is why, by default the OS prevents any other socket to bind to the same ip/port unless s1 (not s2!) explicitly allows it through the SO_REUSEADDR option.

Why did it work on your computer:

It worked on your computer not because your sender sets the SO_REUSEADDR but very likely because you set the SO_REUSEADDR also for your multicast receiver. By doing so, your multicast receiver (assume it's started before) allows other sockets from other programs (your multicast sender) to also bind to the same port, even if your sender should not do this as explained by Gaiëtan.

Why did it failed on the scoring system:

Simply because the scoring system starts a multicast receiver before your sender script in order to read the multicast messages sent by your sender. This multicast receiver does not set the SO_REUSEADDR (because there is no reason to allow any other program to receive on the same port). As a consequence the scoring system's OS forbids your sender to bind to the same port even if your receiver uses the SO_REUSEADDR. Indeed, it not your sender's decision to make.

In the lab, we suggest the use of the SO_REUSEADDR in order to avoid some corner-case effects that arise when you kill and restarts the scripts within a few seconds. But for your future jobs after graduation, please note that setting SO_REUSEADDR "by default" is not a good practice. This option should be set only after careful consideration of the security risks: by setting this option you explicitly tell the OS that it's fine if other applications receive messages that were intended to you.

For a better understanding of bind(), I also recommend doing part 1.1 (and having a look at CodeA and CodeB), but don't hesitate to then ask if it remains unclear.

Ludovic