|
|
In order to join a source-specific multicast group I am trying the new socket module. I am able to join the multicast and start receiving datagrams by spawning the function below. The gen_udp module does not support joining a source-specific multicast currently.
active_socket(Socket, Parent, Timeout) -> case socket:recvfrom(Socket, 0, [], Timeout) of {ok, {#{port := Port, addr := Addr}, Data}} -> Parent ! {udp, Addr, Port, Data}, active_socket(Socket, Parent, Timeout);
{error, Reason} -> Parent ! {error, socket, Reason}, active_socket(Socket, Parent, Timeout)
end.
The multicast is a 45Mb RTP MPEG-TS stream. I am able to receive and verify the RTP sequence number successfully. However, about every Timeout period, in the function above, there are a number of datagrams dropped, that is, the RTP sequence number has a gap of about 200. This continues to happen as long as the process runs. Between the drops everything looks fine.
As you can see, my approach is to simply have a recvfrom pending at all times so when a datagram arrives the recvfrom returns, I forward the datagram and call recvfrom again. The Timeout is simply to avoid recvfrom returning with no data.
Thanks,
Mark.
|
|
Correction. The dropping of datagrams is NOT related to the Timeout, but happens at about 5 minute intervals regardless of the Timeout. Just a coincidence that my Timeout was set to 5 minutes.
Mark.
In order to join a source-specific multicast group I am trying the new socket module. I am able to join the multicast and start receiving datagrams by spawning the function below. The gen_udp module does not support joining a source-specific multicast currently.
active_socket(Socket, Parent, Timeout) -> case socket:recvfrom(Socket, 0, [], Timeout) of {ok, {#{port := Port, addr := Addr}, Data}} -> Parent ! {udp, Addr, Port, Data}, active_socket(Socket, Parent, Timeout);
{error, Reason} -> Parent ! {error, socket, Reason}, active_socket(Socket, Parent, Timeout)
end.
The multicast is a 45Mb RTP MPEG-TS stream. I am able to receive and verify the RTP sequence number successfully. However, about every Timeout period, in the function above, there are a number of datagrams dropped, that is, the RTP sequence number has a gap of about 200. This continues to happen as long as the process runs. Between the drops everything looks fine.
As you can see, my approach is to simply have a recvfrom pending at all times so when a datagram arrives the recvfrom returns, I forward the datagram and call recvfrom again. The Timeout is simply to avoid recvfrom returning with no data.
Thanks,
Mark.
|
|