IP Buffer size - truncated at 256 bytes
xAPPO
Posts: 5
Tackling my first AMX application and it's an IP based application. I am wishing to receive UDP packets on a Netlinx-3000. What I am finding is that in the data event string handler only 256 bytes max are being returned in data.text and the remaining data in any one UDP packet is lost.
I thought this would be resolved when I moved to using a larger buffer but it seems not. Again the buffer is working fine but it still only ever contains the first 256 bytes from any one UDP packet. I am checking the Length_String / Length_Array after every UDP message and it ceilings at 256. Is there something else I should be doing, like setting a UDP max packet size or something ? My UDP packets could contain data occupying upto 1500 bytes.
Would appreciate any pointers to where I'm going wrong
K
I thought this would be resolved when I moved to using a larger buffer but it seems not. Again the buffer is working fine but it still only ever contains the first 256 bytes from any one UDP packet. I am checking the Length_String / Length_Array after every UDP message and it ceilings at 256. Is there something else I should be doing, like setting a UDP max packet size or something ? My UDP packets could contain data occupying upto 1500 bytes.
Would appreciate any pointers to where I'm going wrong
K
0
Comments
You're not doing anything wrong. I found this bug (or limitation) last year and posted my findings with sample test code in this thread:
http://www.amxforums.com/showthread.php?t=313
I thought at first it might just be a problem with the NI-700 (since that was all I had at the time for testing) however it appears to be an issue across the NI series and apparently it hasn't been resolved yet. I'm glad I'm not the only one who finds this to be a troublesome limitation. Hopefully someone from AMX is listening in and will address this issue.
I know it's not the answer you are looking for but I can confirm you aren't doing anything wrong.
And welcome to the AMX forum!
Well at least I'm not doing it wrong but that's really scuppered this whole project then :-( Short of using a UDP receiver on an intermediary PC and resending to the AMX kit as TCP which is horribly bandwidth inefficient . I am really surprised such a restriction is still in place - it really makes the applications limited and the UDP implementation poor. I am trying to participate in a UDP based control protocol between many devices.
I am an 'International DOD' on AMX's site (dealer of distributor) which means I can't open a support case ticket to AMX direct and have to progress this through my distributor which I shall do, but it will take time. Did you by any chance open a case with AMX on this ? Or could you ?
Just thinking about ways around this I see references to i!-PCLink Plus but it is not on the AMX site any longer - is this still available, or is the Active-X rolled into some other app now ?
K
xAPPO ? No I never did anything other than post the issue in the forum here and it didn?t generate any interest so I kind of just dropped the whole thing and have reluctantly avoided using UPD. I?ll give tech support a call and voice the issue. I have no exposure to i!-PCLink Plus but I think I remember it being mentioned here before so you might want to try searching the board. If you know VB you could write a small app to receive and relay your UDP messages while converting them to TCP. I realize it puts an extra layer of icky stuff in the mixture including a PC but off hand I can?t think of any other way to do it.
Dave - my buffer grows OK and has successive messages in it but each one is truncated at 256. I tried not using the event handlers at all and just examining the buffer after a few messages had been received.
K
Joe,
I played around with your sample program on an ME260 and it demonstrates the same behavior you guys are seeing on the NI controllers so there is nothing Master specific about it. Based on the testing results, it appears to be a UDP buffer size or packet handling issue and not an IP limitation (it is a transport layer issue) since TCP and UDP tests behave differently.
A couple of observations - TN156 indicates that the maximum packet size for TCP/IP devices is 256 but it is unclear what this means (send or receive, TCP or UDP or both, ...). I think your program demonstrates clearly that TCP packets larger than 256 bytes can be received and that the packets are broken into chunks as they are delivered to your buffer. UDP, on the other hand, seems to only support packet sizes up to 256 bytes as TN156 suggests and the rest of the packet is dropped. I wonder if the 256 byte limitation used to apply to TCP but this was changed leaving the limitation in effect for UDP.
The second observation is that TN156 also mentions a 2012 byte limitation with the note virtual devices. When using the 2048 byte send TCP option in the test program, Netlinx throws a runtime exception (on the ME260) indicating that the maximum TCP send packet size has been exceeded and further noting that the maximum send size is 2012. The same runtime exception is thrown when a packet size of 2048 (or larger) is sent using the UDP connection.
Line 11 :: SendTheMessage packet too large wCmd=bd8465 len=2120 src=3 - 06:57:52
This seems to correlate somewhat to the TechNote. I suspect that when you talk to AMX Tech Support (and they talk to engineering), that you will be told that the UDP limitation is by design. It would be interesting to know what the maximum inbound TCP packet size is in Netlinx since it is clearly not 256. On the send size, 2012 is clearly the largest single packet size you can send on a TCP or UDP connection at least on the ME260. This correlates to the STRING event for the TCP connection which verified that only 2012 bytes were received in the buffer. I do not have a way to generate arbitrary UDP and TCP packets from a non-Netlinx source and to send them to Netlinx so I don't know if the 2012 byte restriction applies only to packets sent from Netlinx or if this is also a limit on the size of inbound TCP packets. I would hope that this would not vary across the different types of Masters but stranger things have happened.
Reese
Good catch, Reese. However, I don?t think it has anything to do with either TCP or UDP. I also thought that 2012 was the largest TCP packet and stated that in the other thread but I was wrong. I?m fairly certain that it?s just a SEND_STRING limitation and that?s why the exception was thrown. I wrote a quick VB app that blasted a 16K TCP message to Netlinx and it swallowed the whole thing without a problem. I change it to UDP and it chokes after 256 bytes.
I sure hope that?s not the case. I can?t imagine why UDP would be crippled like this compared to TCP on purpose but as you stated ? stranger things have happened.
Thanks for the feedback.
Joe,
Good point on the SEND_STRING limitation versus a TCP limitation. The TechNote also mentions 16,000 as a limitation and this is consistent with your testing using a non-Netlinx TCP client. SEND_STRING size limitations is another thing that annoys me from time to time since the maximum size of a SEND_STRING is different for different devices but is not documented (at least clearly) as to the limitations. I find myself using trial and error to discover the limits. Sounds like an updated TechNote that describes limitations on SEND_STRINGs, buffer sizes, packet sizes, etc. would be generally useful. The TechNote we have been referencing does not include all devices or device types (such as touchpanels) and could be cleaned up a little to make the limitations more clear.
I don't do a lot of UDP (opting for TCP instead) but let me know what you find out from AMX. Thanks,
Reese
If you have a 20k buffer, and have a device send between 16 and 20k of data, or read a file off the DOC, or whatever, the data above 16k >is< there, BUT... You have to GET_BUFFER_CHAR or REMOVE_STRING on the buffer in order to get your data to shift down below the "ceiling" before you can directly access it.
- Chip