|
From: | David Empson |
Subject: | Re: [lwip-users] Not a bug report but a question regardingbroadcasting |
Date: | Thu, 07 Feb 2008 11:35:24 +1300 |
This isn't really an LWIP problem, but hopefully
the following should explain the issue or at least point you in the right
direction for further research.
If your LWIP host is trying to transmit to a
specific IP address (192.168.1.49) and there is no device on your network with
that IP address, then it won't actually send any of the UDP data. It will be
sending ARP requests ("who has 192.168.1.49") and getting no reply, so it will
throw away the UDP data. This explains why you aren't seeing the data on the
network.
Multicasts don't need a specific device to receive
them, and therefore don't need ARP to find the destination device's Ethernet MAC
address. They will be sent using Ethernet multicasts.
You won't be able to get a LAN multicast out
to a specific device on the Internet by doing something as simple as NAT
translation in the router. It also isn't possible for the router to "pick up" an
existing LAN unicast and resend it via NAT.
NAT operates by the external host sending a packet
to your router's public IP address, and the router maps that to a specific
internal IP address and port (given its configured rules), by replacing the
destination address and port fields in received packets and forwarding them to
the LAN. The router also remembers the mapping so it can be used for
outgoing traffic.
For outgoing traffic, the LAN host must send
the packets addressed to the external host and port (matching the mapping that
the router has remembered). The router picks them up and does the NAT
translation on the way through, replacing the source address and port fields
with the values from its rule.
You are trying to do NAT based on the destination
address and port in packets sent by your LWIP host. That isn't going to
work. NAT operates from the source address and port for outbound
packets.
In order to support sending an MPEG stream over the
Internet via NAT, the router must have a NAT rule which maps UDP external
port 7777 to your LWIP host's IP address and port 1111. Your LWIP host is going to have to do something like this:
1. Wait until it receives a UDP packet on port 1111
which requests the MPEG stream.
2. Save the source IP address and port from
that UDP packet.
3. Send the stream to the saved IP address and
port.
This will produce a unicast UDP stream over the
Internet to a specific IP address.
If you also need to send the MPEG stream as a
multicast over the LAN, you will need to send it twice: the multicast and the
directed external connection (once you know where you are sending it). To
support multiple external recipients, you will need to support sending several
copies of the MPEG stream at once. You could offload this from the
LWIP host by having another host on the LAN receive the multicast and
resend it to subscribers over the Internet. There may even be an existing
product which can achieve this: have a look at Apple's "QuickTime
Broadcaster".
I'd say a safer approach would be to require the
external host to regularly send "I still want to receive the stream" packets,
and your LAN host will stop sending the stream if it times out on receiving
these "keep alive" packets.
The other approach is to do everything with
multicasts over the Internet. This will require the use of a router which
fully supports multicasts, your LWIP host must use IGMP to report
membership of a multicast group, and there may be additional complexities at the
other end. You should do more research on what is involved with multicasting
over the Internet before attempting this. (LAN multicasts are easy.
Internet multicasts are not.)
You might like to investigate RTP as a possible
approach for sending your stream over the Internet (whether you do it as a
unicast or multicast). RTSP may also be relevant.
----- Original Message -----
|
[Prev in Thread] | Current Thread | [Next in Thread] |