Home/Support/Support Forum/Has anyone managed to get the 9215 to receive more than 8192 bytes via UDP?
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

Has anyone managed to get the 9215 to receive more than 8192 bytes via UDP?

0 votes
Hi,

I am using NET+OS 7v5 and trying to receive > 8192 bytes of data via UDP.
Despite setting the socket options:
Code:
socket_optionLen = sizeof(ulSocket_option); result = getsockopt(testSocket, SOL_SOCKET, SO_RCVBUF, (char *)&ulSocket_option, &socket_optionLen); if (result == 0) { #ifdef MATRIX_IO_MESSAGES printf("\r\nDATAPORT_IO_INIT:Socket rx buf length = %d\r\n", ulSocket_option); #endif ulSocket_option = 0xFFFF; result = setsockopt(testSocket, SOL_SOCKET, SO_RCVBUF, (char *)&ulSocket_option, sizeof(ulSocket_option)); if (result == 0) { #ifdef MATRIX_IO_MESSAGES printf("\r\nDATAPORT_IO_INIT:Set socket rx buffer to %d\r\n", ulSocket_option); #endif result = getsockopt(testSocket, SOL_SOCKET, SO_RCVBUF, (char *)&ulSocket_option, &socket_optionLen); if (result == 0) { #ifdef MATRIX_IO_MESSAGES printf("\r\nDATAPORT_IO_INIT:Socket rx buf length = %d\r\n", ulSocket_option); #endif } }

If I send > 8192 to the device, recvfrom() never returns with a non-zero value.

Is there a header file that I also have to modify?

Any suggestions appreciated!

Regards,
David
asked Sep 9, 2013 in NET+OS by david.lockyer New to the Community (15 points)

Please log in or register to answer this question.

3 Answers

+1 vote
I want to give this question a definitive answer. I have done some testing. There is a hard limit on the number of bytes allowed on a recvfrom call in NET+OS. That number is 8192. Sending 8193 will cause the receipt to be blocked far down in the stack. Further changing the size of the receive buffer through calls to setsockopt has NO affect on this limit. From what I saw of David's code non-blocking as well as blocking recvfrom calls are both affected by this limitation. This is NOT something that is planned to be changed.
answered Sep 17, 2013 by dakotas_dad Veteran of the Digi Community (694 points)
Thanks for the information,

I will make sure our windows programmer limits the size of UDP packets sent to the 9215 CPU in one go.

Regards,
David
As an aside, I was investigating a memory leak in NET+OS at the time I discovered this issue.

I now know that sending large UDP packets with the sendto() function causes the TCPIP stack to leak 4 bytes for each call, Digi now know about this issue and are (hopefully) fixing it - they have given me case id of NETOS-39.

I suspect this is also related to case NETOS-38, where the TCPIP stack leaks memory when fetching a large file from the web server.

So, if anyone has suffered from unexplained lock-up of networking functions, talk to your local sales contact and ask them to get cases NETOS-38 & NETOS-39 resolved!
0 votes
I've got the same problem. I try to send an image of 160*120 pixels (19200 bytes) over an udp socket which I have to split up in blocks of 9600 bytes. Then data is transmitted correctly. If I send it as one block it does not send the data.

I'm working with an me 9210. I don't know if you can set a setting in any config file to change the maximum size of an udp packet. My solution around it is to split the data up in smaller packages and send them seperately. Isn't this a (temporary) solution for you?
answered Sep 11, 2013 by Chris1986 New to the Community (1 point)
0 votes
I don't know if it is related but there is a macro in NetOS 7.4 TM_SOC_SEND_Q_BYTES in the netos74\src\treck\include\trmacro.h file which is set to 8192. Obviously changing this will impact memory usage...

Regards,
Peter
answered Sep 11, 2013 by petermcs Veteran of the Digi Community (1,128 points)
Hi Peter,

Thanks for that, I will give it a try - in particular the TM_SOC_RECV_Q_BYTES macro is what I think I will need to alter..

Regards,
David
David
   Most if not all macros in the tr*.h files are used to build the track stack and thus their values would be fixed and immutable in the track stack. So changing such values will not alter the behavior of the stack.
OK, thanks for letting me know... For 9215 to 9215 communications it is not really an issue, just PC to 9215 communications, but for now we can work around the problem.
...