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

Reply via email to