I have repeatedly seen cases where the initial optimistic assumptions turned out to be invalid, e.g:
- the distinction between LAN and internet is grey, not black and white; internal bridges and routers can cause unwelcome surprises
- the internal network isn't correctly understood
- somebody else modifies the internal network without you realising, making your assumptions invalid
- the scope becomes expanded so that the traffic has to cross the net
*grin* That sounds awfully familiar. Luckily all of these have to do with a large subset of Homo Sapiens being a bunch of stupid mthrfkrs. If you manage to avoid being part of that subset and actually engage brain, then all the above points can easily be avoided for your own projects. As soon as any other person comes near it you may have to adjust expectation values.
My reply to the OP is partly based on his previous posts. Those suggest that he is doing some data acquisition on the fpga side, and would like to pump the acquired data to the PC which is directly connected to the fpga board via a single short cable. Furthermore those posts suggest it is a personal project, not some paid for by customer design. And I also suspect he hasn't done any projects with a softcore in it yet. Read: if tcp, then softcore, and thus toolchain learning curve.
Now given all that, it seems reasonable to start with UDP over a single short cable. And as suggested in a previous post, you DO keep internal counters such that you can do a sanity check and verify your assumptions.
The purpose of the sanity check is purely to warn you of any packet loss. The expectation is that you will not encounter any such loss. But should it happen due to the cat gnawing on the cable overnight then at least the error will not be silently ignored. The assumption here is of course that you either don't care about a few dropped packets, can work around it, or just rerun the experiment.
A simple counter + client side checks are far less expensive than a tcp implementation. Granted it is also far less robust, but for certain jobs the safety of tcp is nice to have, but not strictly required. So then it becomes an engineering decision of what to spend your time and resources on.
I find that the direct cable link + static arp + udp (with counter in the payload for sanity checks) gives good results for a low amount of implementation effort.
And before I forget, another low cost implementation that is useful is to implement icmp echo + reply (aka ping). For two reasons:
- regular boring ping, should you want to have a remote quick check for signs of life of the fpga
- icmp with payload for SIMPLE commands
Or you can just do the same thing all with UDP on port number base, whatever is your preference. Incidentally, the use of icmp in this way pretty much also implies that you intend to use it without any routers etc in between. Because as per RFC-forgot-number those routers are totally within their rights to mess up the above icmp.
But then again, if you want to argue
"but it has to connect over the internet", then assume that any implementation you will come up with is going to be suboptimal and thus set up an stunnel through which you pipe all your crappy insecure content.
All that to say that for simple data acquisition in a lab setting with direct cable UDP can be quite sufficient and easy to implement.