Hey community! It seems like the discussion about TCP and UDP has been ongoing regular on discourse and I would love to spend some time looking at how the issue can be improved. Disclaimer: I’m not at all an expert in networking stuff. Just trying to provide some help/testing :smile: The Spark fi…

Test (3): Code can be found here http://community.spark.io/t/udp-received-dgram-boundaries-lost-read-parsepacket-available-all-broken/3800 This code sets up the Core as a slow reader of UDP packets. It delays 1000ms between reads. This allows the fast sender to send multiple packets. They should be…

@kennethlimcp - I suggest we start with TCP, side-stepping discussions of protocol unreliability and the incessant hair-splitting that accompanies it. The TCP case is particularly interesting how that the ACK/NAK responses have been pushed up to cc3000 host events, allowing applications to assist w…

@mdma , this is a large amount of functionality to test, and so one has to start somewhere, and if that is with TCP, so be it. But there really is no hair-splitting going on: UDP is as I describe it. And it is impossible for @kennethlimcp or anyone to test that UDP (or TCP) works if there is no func…

I’m performing an extremely simplistic test where the core behaves as a Server OR Client. Observing the output of the transmission to determine what’s the packet loss rate in a given time interval. That’s what I’m doing to approach the problem as a total beginner who might want to use the TCP/UDP f…

Packet loss: Packet loss in UDP does not signify a problem, necessarily. By definition of the protocol. Packet counts in TCP cannot be used reliably as all you are guaranteed by TCP is that the bytestream arrives intact, in order, no losses, no duplications. But the number of received packets need…

[image] kennethlimcp: I have yet to receive any test case [image] UDP received DGRAM boundaries lost: read(), parsePacket(), available() all... Firmware UDP vs TCP (I write this intro to prepare the ground for my descrip…

@psb777 , not sure if i’m testing it correctly but i observe that UDP is observing the rule of one datagram and not joining them together. I have a code running on the core: UDP udp; unsigned char buf[50]; void setup() { for(int i = 0; i < 50; i++) buf[i] = 0x00; udp.begin(remoteP…

What is the content of the sent packets? Is it “1234567890” or is it 5 of those, 50 chars? If you read your UDP packets as quickly as they are sent (or more quickly) then you will never see UDP packet concatenation. What you need to do is slow down so that there is time for two or more packets to a…

I’m trying to test one parameter at one time so checking a few at one go might not be that appropriate. Following your suggestion, i modified my code to do delay(3000) each loop and send 1234567890 at 1 second intervals. The result seems fine except that the core gets knocked offline probably due …

I’m unsure I entirely understand what you have written above, and I cannot see your code, but it seems perhaps the latest TI patch has made a significant improvement to the UDP functionality. If so that will be very very welcome. But I would be very interested in you running my code, so we can see w…

TCP or UDP issues consolidation

Troubleshooting

psb777 November 22, 2014, 2:09pm 18

Topic		Replies	Views
Simple UDP program breaks the core Troubleshooting	89	15625	October 9, 2014
Unreliable UDP: crashes/freezes when sending at high frequency Troubleshooting	28	10971	June 5, 2014
UDP issues and workarounds Troubleshooting	29	15036	September 2, 2015
RESOLVED: TCP packets retransmitting and failing after approximately 25 seconds Troubleshooting	12	7766	June 11, 2014
Hard fault caused by the TCPServer example from the Spark docs and a simple Python client Troubleshooting	52	13138	April 15, 2016

TCP or UDP issues consolidation

Related topics