-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Number of received bytes differ from message length (SmplMsgConnection::receiveMsg). #25
Comments
'looked at the packets using Wireshark': did you use Could you attach / upload a Wireshark capture somewhere? |
Yes I have, the file can be downloaded here, but it will expire in one day. |
I have an update on this, adding a |
Ah, this might then be related to swri-ros-pkg/issues/23. Yes, the first few |
I think this assessment is probably correct. While Libor's fix probably solves this issue in the short-term, I think we should hold off on pushing this change to the public repository. This change causes the socket code to wait forever until the requested bytes are read. In the event of datastream errors, this might lead to long waits with no errors. A better solution would be to properly handle both split and merged simple_message packets in a mechanism that also provides timeout-capable waits. So that we could wait for the expected # of bytes, possibly across multiple packets, but return after a specified timeout period if the expected # of bytes is not received. This is indeed the issue logged in bug #23. Please close this bug if your issue is resolved. |
One idea might be to utilise the following pattern:
Fairly standard. If there aren't enough bytes, wait for them to come in the next |
That's mostly what I was thinking. Here are two possible variations:
We should probably log this as an enhancement, or continue discussion on the original bug, since I don't know that the current discussion is directly relevant to Libor's error messages. |
This is probably a good solution, but how would we test it? Has anybody seen this error before? Is there anything special about Libor's setup that would cause this? Perhaps network topology? We've always communicated with the robot on a small (single switch) network. |
I think testing would be fairly easy. We could "hand-craft" TCP message packets that are either the combination of two SimpleMessage packets, or split a single message into multiple packets. These packets could be sent (with optional time-delays) to test the merged/split packet handling. I think that with TCP_NODELAY set, all packets should be sent "immediately". I do remember this being an issue before. I can't remember the details, but I think it might have been Ed Venator using a wireless link to his ABB robot. The wireless delays caused split packets. |
If you go the receive timeout way, why not just use a As for the multiple-packets-in-single-TCP-frames or single-packet-over-multiple-TCP-frames: I've been able to reproduce that fairly easily (at least for the Fanuc). Either set a very high update rate on the controller side (so send out a lot of packets/sec), or configure the socket in 'interactive' mode. The latter is probably mapped onto |
As for testing: if you mean manually: there are tools that can replay a Wireshark capture, I think I can get some fairly complicated (de)serialisation situations using the technique described above. |
In my opinion, But I still think the |
Another related issue (google code): https://code.google.com/p/swri-ros-pkg/issues/detail?id=55 |
…ecuted in parallel with colliding on the same ports
Fixed |
When testing the motoman driver, I got this error:
When started with DEBUG logging level the ouput.
So, the problem is that the size of the ByteArray returned by
receiveBytes
is shorter that the expected message length (that should be checked). I have looked on the packets using Wireshark and they seems to be ok.The text was updated successfully, but these errors were encountered: