HagertyRobotics / ftc_app_networked_simulator

This is a First FTC robot controller app that will provide a networked simulator in place of a USB connected Modern Robotics controller.
MIT License
9 stars 8 forks source link

Rebuild networking to use TCP vs UDP #6

Open dmssargent opened 9 years ago

dmssargent commented 9 years ago

The UDP systems requires bonding of ports to a selected number, and if/when the app crashes the port may get leaked. The TCP system requires only one socket to run, (two, if multicast is enabled) one in UDP mode for listening for a multicast. The UDP is also using hardcoded strings for IP addresses in stead of relying on validated user input.

What I have done:

What doesn't work:

What we need to do:

I opened this early so I could get feedback from you and to request changes, it is not ready to be considered alpha yet

dmssargent commented 9 years ago

I resolved the issue with the ConcurrentModificationException, so that a dead spin could show up.

dmssargent commented 9 years ago

Dead spin fixed, plus a few minor touchups to identify now your code is throwing: org.xml.sax.SAXParseException: Unexpected token (position:TEXT ?@1:2 in java.io.InputStreamReader@376a700e). I will go see if the data is valid in the parser, or just the code running the XML is expecting a new format of XML.

HagertyRobotics commented 9 years ago

Thanks. I'll start working on merging it into a branch to try it out. I just committed a lot of changes trying to get the GUI working better along with some restructuring.

dmssargent commented 9 years ago

Sorry, about any delays, any ideas about any problems or have suggestions?

dmssargent commented 9 years ago

I am working out why the XML is getting corrupted by the exchange. How would the Device List exchange work best for you?

HagertyRobotics commented 9 years ago

Hi, I'm a little confused. When you were working on your new networking code, I was also restructuring some of the classes and also I changed the package names to ftccommunity. I then merged my new code into master. When you issued your 2nd pull request I took a look but saw that because I make so many changes that I had to do some work to merge it with my latest develop branch. I haven't had a chance to merge it because I was working on getting the new ftc_app release working with the existing code. I guess the XML parser stuff above is just added to your original networking code. My question is, when you are working on your networking code, is it also merged with my latest master branch?

dmssargent commented 9 years ago

Some of the times, I am trying to stay somewhat recent, but I had to take a break (from coding) when you slightly before you started pushing, so I am trying to catch up. My side of Git went slightly nuts on this repo, so thats why there is multiple commits with the same comments.

dmssargent commented 9 years ago

Can I try to repackage some common items in it a module that both use? The current problem is that when the OpMode is switched it doesn't switch and it is stuck in the init phase.

HagertyRobotics commented 9 years ago

I am finally looking at your code. I have to catch up with all the work you did! I did get the new SDK updated and working in a separate ftc_app repository along with changes on the PC side in my develop branch.

dmssargent commented 9 years ago

Okay, I figured out why it gets stuck in init, its completing a send then the client tries to reply back but a) the packet is getted corrupted b) the system for saving the packets is getting blocked or is not functioning, my bet is on the former. Right now commit a9ea7e0 is the best bet for looking at somewhat working code, the latest additions have the GUI closing cleanly, but the networking sections went all crazy, when I tried to optimize memory usage even more. I will try to get all of that protocol stuff functioning before I get the new app components folded in (so I don't have to work out both problems)

HagertyRobotics commented 9 years ago

I tired your code but it seems I am missing the SimulatorData class. Did you check that in or am I doing something wrong?

dmssargent commented 9 years ago

That is a problem. That file is generated from the protobuf/Data.proto. You can use the copy of it in the App, otherwise you can download protoc and rebuild the file, or you can wait a tad a bit for me to force the file to be there.

HagertyRobotics commented 9 years ago

No problem. I'll just get it from the App. Thanks.

dmssargent commented 9 years ago

I am still figuring out why the client is not replying back to the server, but I improved/polished lots of things

dmssargent commented 9 years ago

The bug is apparently within the server receive Non-Heartbeat type. I validated the following components:

Server

Client

HagertyRobotics commented 9 years ago

Thanks. I've been working on making sure I understand the communication between an actual Legacy Module and the Phone Still trying to understand switching from read and write modes.

dmssargent commented 9 years ago

I am going to try to re-read the Netty and Protobuf documentation, and see if our software mentor can spot the bug. If all else fails, I am going to need fresh to eyes to spot that bug.

dmssargent commented 9 years ago

I seem to have fixed the problem bug, now we can see it gets stuck on init with waiting on the Simulator Device feedback. So, I probably missed something when I updated the simulator to the latest version, I designed the networking to be backwards-compatible with your code (as in the functions that handle specific things should have the exact same behavior as before). I did add the throwing of an Interrupted Exception to the functions that wait for user input, to allow safe termination. Can you specify an overview of how each component is networked, or evaluate your module code to see if I only partially changed something.

HagertyRobotics commented 9 years ago

Sure, I will look at it right now. After a lot of tracing with an actual device, I now understand more about what is going on in the modules. Thanks.

dmssargent commented 9 years ago

Let me know, if you find the mistake. Do you want a layout of how everything works in the networking?

HagertyRobotics commented 9 years ago

yes, if it is not too much trouble. Thanks.

dmssargent commented 9 years ago

The Network Manager class takes care of keeping track of every send, and the received data. The received data is getting dumped into the Network Manager, then gets sorted by a "process queue" thread that moves everything to the right place. The Server/Client classes are Runnable classes that taking care of the bootstrapping the communications, it also handles the configuration options. The *Handler classes take on creating sends, and receiving things. The Decoder/Encoder classes change the Data class to a ByteBuf (an extension of the ByteBuffer) , and it gets written to the data stream, and vice versa. Sending: NetworkManager.requestSend (builds the Data object) - Handler -> NetworkManager.getNextSend() -> Encoder -> Data gets flushed to the stream

Receiving: New data appears in the stream -> Decoder -> Handler -> NetworkManager.add - processQueue - getNextMessage (callable) (-> getNextData (gets the data encoded (used ASCII to encode)

There should be a protocol.md that goes into the communcation

dmssargent commented 9 years ago

Have you gotten anywhere? I have been busy trying to get 4 teams started on the learning the new platform.

dmssargent commented 9 years ago

I am thinking that I already need to do a major rewrite of my own code to increase readability and performance.

HagertyRobotics commented 9 years ago

Same here. Working on getting started. I have more time now. I'll see what I can do. I like what you did but I need to make some changes to merge it with the current code.

dmssargent commented 9 years ago

Okay, though what changes need to be made to push it to the current code, even you get settled down with this keep this pull request open, so we can collaborate on the optimization and rewriting the things that need to be rewritten

dmssargent commented 7 years ago

If you are still looking at this feed, can you rewrite and point me towards the MR USB communication protocols on the PC side? I can re-implement the hooks that you had previously to emulate devices, and rebuild the TCP stack to work correctly.

HagertyRobotics commented 7 years ago

Hi! I just saw your note. Yes, I would like to get back into the simulator. I need a few more weeks to see where we end up this season. Thanks for your interest.

dmssargent commented 7 years ago

Sorry for responding 23 days after your reply. I'm busy with FTC and FRC as well, so my time is limited right now. But I should be free to help out sometime soon.