|
Re: FRC Java TCP client
OBTW,
UDP's is unreliablity only results in lost messages when resource contention exists. I doubt there will be much of that in a well-designed version of a specialized appliance like a co-processor communicating with a robot controller.
To remove the possibility of lost or out-of-order messages, if the other solutions (already posted) hadn't been available, you could implement a simple user-code handshake to ensure reliable, ordered delivery of UDP messages between the two processors.
I know that an efficient off-the-shelf TCP implementation is almost always the proper way to avoid reinventing the wheel; but one shouldn't be scared of reinventing parts of it, if (and only if) necessary.
Ensuring reliable (in the connection-oriented communication sense) and ordered delivery isn't all that hard, and wouldn't add much overhead to an intra-robot comm link.
__________________
Blake Ross, For emailing me, in the verizon.net domain, I am blake
VRC Team Mentor, FTC volunteer, 5th Gear Developer, Husband, Father, Triangle Fraternity Alumnus (ky 76), U Ky BSEE, Tau Beta Pi, Eta Kappa Nu, Kentucky Colonel
Words/phrases  I avoid: basis, mitigate, leveraging, transitioning, impact (instead of affect/effect), facilitate, programmatic, problematic, issue (instead of problem), latency (instead of delay), dependency (instead of prerequisite), connectivity, usage & utilize (instead of use), downed, functionality, functional, power on, descore, alumni (instead of alumnus/alumna), the enterprise, methodology, nomenclature, form factor (instead of size or shape), competency, modality, provided(with), provision(ing), irregardless/irrespective, signage, colorized, pulsating, ideate
|