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

Question

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

Answer 1

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.

Comments

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!

Answer 2

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?

Answer 3

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

Comments

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.