Hi Noam,
Many thanks for the additional hints! This project (as you guessed) is
also VOIP. It will use RTP, but the code fragment I sent is a
stripped-down version of the packet sender, that I used when I started
to find problems. There are separate threads to handle discovery (using
NetBIOS, as only my devices need to discover each other), set-up user
interface HTTP server, also SIP and RTCP which I haven't written yet.
Currently, all threads except the RTP/audio and lower level LWIP are
disabled for testing.
I looked at the first link you sent, and the Netconn example is pretty
close to where I started - I will copy it into my code and see what it
does! I haven't had a chance to look at the others yet.
Thanks again,
Mike.
On 28/07/2016 09:07, Noam Weissman wrote:
Hi Mike,
Above all your testing…
Many years ago I worked on a VOIP project and implemented portions of
RTP protocol.
From that experience, I think you should not reinvent things. Sending
streaming data over UDP
without some protocol will eventually cause you to lose or miss data.
UDP packet ordering is not guaranteed so you must have some protocol
to carry the data.
What do I mean?… TCP will guaranty that the order of sent data is the
same order it is received.
Under UDP data packets are not guaranteed to be received in the same
order they were sent !.
To overcome this problem and still benefit the faster transfer under
UDP, RTP defines a time stamp
for every packet. This way you push data packets to a link list on TX
side, every packet sent out has
a time stamp. A real accurate time stamp
On the receiving end you also hold a link list. Received data packets
are checked and if the time stamp
is older than the last handled packet is discarded…
This is in short. There is much more, but I am sure you can read about
RTP and more modern video/audio
streaming protocols in details.
Another overlooked issue that I learned the hard way:
if you send TCP data, if connection is dropped or there is an error,
eventually data is removed from the
TCP stack and memory is released.
People FORGET that when you send UDP data and remote IP is not
reachable or wrong data is piled
at the TCP stack and never freed. Eventually causing the TCP stack to
crash or have memory errors.
The reason is that if you send data to a wrong IP or domain and TCP
stack does not have the destination
MAC address so it will issue ARP messages. What if the ARP message
fails ?... The TCP stack does not know
where to send the UDP packets. As a result if you continue to send UDP
packets they are added to the
waiting packets to be sent. They are never sent, memory is not freed
and eventually you are without
memory !!
I hope the above helped in some way.
BR,
Noam.
*From:*lwip-users
[mailto:[email protected]] *On Behalf Of
*Mike Fleetwood
*Sent:* Thursday, July 28, 2016 10:42 AM
*To:* [email protected]
*Subject:* Re: [lwip-users] Problems with sending UDP packets in FreeRTOS
Hi Noam,
Thanks for the response.
I will look at the links you sent, later today - see what I can discover.
I originally had the buffer creation/deletion inside the loop - so it
was a fresh buffer for every send. The final version needs to do this
anyway, as the audio packets to send will vary slightly in size. I
only changed it when I was trying to discover the cause of the ERR_USE
return.
What I don't understand is why/how repeated sends with the same
source/destination address and port should (after a time) cause an
error. My understanding is, this should only happen if we attempt to
create a new connection with the same character as an existing one -
as far as I can see, my software should keep using the original one
(changing the destination address only if needed).
Many thanks,
Mike.
On 27/07/2016 21:46, Noam Weissman wrote:
Hi,
I never worked with netconn so I am not sure. I worked mainly with
RAW API.
See these:
http://www.ultimaserial.com/avr_lwip_udp.html
lwIP Example, How to write an UDP echo broadcaster on ...
<http://www.ultimaserial.com/avr_lwip_udp.html>
www.ultimaserial.com <http://www.ultimaserial.com>
lwIP UDP Echo Broadcaster Example using Raw API, Socket or Netconn
approaches UltimaSerial . Windaq Add-ons
https://lists.nongnu.org/archive/html/lwip-users/2010-04/msg00053.html
http://www.freertos.org/FreeRTOS_Support_Forum_Archive/April_2009/freertos_Start_lwIP_UDP_in_a_Task_3216066.html
Seems that in the examples for every send they allocate a new
buffer and after every send the delete it.
For me it looks perfectly sensible.
I hope that helps a bit.
BR,
Noam.
[RTOS Support] Start lwIP UDP in a Task - FreeRTOS
<http://www.freertos.org/FreeRTOS_Support_Forum_Archive/April_2009/freertos_Start_lwIP_UDP_in_a_Task_3216066.html>
www.freertos.org <http://www.freertos.org>
FreeRTOS support forum archive - Start lwIP UDP in a Task
------------------------------------------------------------------------
*From:*lwip-users <[email protected]>
<mailto:[email protected]> on behalf of
Mike Fleetwood <[email protected]> <mailto:[email protected]>
*Sent:* Wednesday, July 27, 2016 6:07 PM
*To:* [email protected] <mailto:[email protected]>
*Subject:* [lwip-users] Problems with sending UDP packets in FreeRTOS
Hi,
I’m hoping someone can help me with a problem that has been
causing me grief for a few days now!
I am writing an RTP audio system, that needs to send a packet of
audio data every 4mS. This is in a multi-thread RTOS environment,
running on STM32F427, with initial code generated using ST’s
“Cube” (wish I hadn’t!). I have threads to handle NetBIOS and
HTTP, but they are all disabled at the moment.
The problem I’m having is that after a variable length of time –
sometimes immediately on start-up, sometimes after half an hour –
the code stops working. The central “netconn_send” returns with
“ERR_USE”. I have tried many variations with this code, all
showing the same problem. None of the other error warnings get
activated, only the GPIO pins set to indicate the error.
Question 1: Why should send return with ERR_USE? At present there
is only one connection and it is only bound/connected once –
outside the loop. I get the same error with connection within the
loop, or if I use sendto instead.
Question 2: Why does this supposedly non-fatal error cause all
lower level LWIP functions to stop? If I have the HTTP thread
running (to show status/fault information) it also stops.
Question 3: Why does not SOF_REUSEADDR mask the error (SO_REUSE is
enabled in lwipopts)?
Many thanks,
Mike.
void udp_test(void *arg)
{
struct netconn *conn;
struct netbuf *buf;
char *data;
err_t err;
uint16_t index;
size_t bufsize = 100;
conn = netconn_new(NETCONN_UDP);
if (conn == NULL) debugmessage("Could not create new netconn for
UDP test<br>");
if (conn != NULL)
{
ip_set_option(conn->pcb.udp, SOF_REUSEADDR);
err = netconn_bind(conn, IP_ADDR_ANY, 5004);
if (err != ERR_OK) debugmessage("Could not bind to port 5004 for
RTP data<br>");
// err = netconn_connect(conn, IP_ADDR_BROADCAST, 5004);
// if (err != ERR_OK) debugmessage("Could not connect port 5004 to
BROADCAST for RTP data<br>");
// while(1)
{
buf = netbuf_new();
if (buf == NULL) debugmessage("Could not create netbuf for UDP
test<br>");
if (buf != NULL)
{
data = netbuf_alloc(buf, bufsize);
if (data == NULL) debugmessage("Could not allocate pointer to UDP
test data in netbuf<br>");
if (data != NULL)
{
while(1)
{
HAL_GPIO_WritePin(CONT6_GPIO_Port, CONT6_Pin, GPIO_PIN_SET);
for (index = 0; index <bufsize; index++)
{
data[index] = index;
}
// err = netconn_send(conn, buf);
err = netconn_sendto(conn, buf, IP_ADDR_BROADCAST, 5004);
if (err == ERR_USE) HAL_GPIO_WritePin(CONT3_GPIO_Port, CONT3_Pin,
GPIO_PIN_SET);
if (err == ERR_MEM) HAL_GPIO_WritePin(CONT4_GPIO_Port, CONT4_Pin,
GPIO_PIN_SET);
if (err != ERR_OK) HAL_GPIO_WritePin(CONT5_GPIO_Port, CONT5_Pin,
GPIO_PIN_SET);
HAL_GPIO_WritePin(CONT6_GPIO_Port, CONT6_Pin, GPIO_PIN_RESET);
osDelay(4);
}
netbuf_delete(buf);
}
}
// osDelay(4);
}
}
}
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986>
for Windows 10
_______________________________________________
lwip-users mailing list
[email protected] <mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/lwip-users
--
FACE Systems Ltd
The Old Boat House
Cadgwith
Cornwall TR12 7JX
T:01326 291031
M:07831 401464
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
--
FACE Systems Ltd
The Old Boat House
Cadgwith
Cornwall TR12 7JX
T:01326 291031
M:07831 401464
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
