Skip to content
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

[tcppros - subscriber] connection header are checked for every tcp packet #32

Open
maxired opened this issue Jul 12, 2012 · 2 comments
Open

Comments

@maxired
Copy link
Contributor

maxired commented Jul 12, 2012

Hi,

using the thc ros stacks, I've been faced to a problem.
Being a subscriber , once a conneciton with another node is establised, the first message contains the connection header. Others packets does'nt contains this header.

In the implementation, we check for the header for every packet.
This sometimes lead to serious problems.

(In our implementation, i'm not sur if we are realy using the header, because we got all the needed information before).

@baalexander
Copy link
Owner

In deserializeMessage, it should be checking if a Connection Header is part of the packet or it's a standalone message (these lines specifically).

I'm sure there's a more efficient way of doing this though. See Issue #1.

@maxired
Copy link
Contributor Author

maxired commented Jul 12, 2012

Hi, I was not aware of issue #1.
I'm not sure to understand the comments

" // If the initial length is less than the buffer, then a connection header was
  // sent first as part of this buffer."

You got to be careful, it's not impossible that two or more messages was sended in the same packets.

From what I understood, the Connection Header is always sended as a first "message" once the connection is established.
That's means that when reading the first packet, you can skip the Header before the message. The header length is buffer.readUInt32LE(4);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants