Is tcp+log.in carrier meant to be used only with RpcServer/RpcClient classes?

[barbalberto]

It would be great to use this carrier to monitor messages from / to controlBoardWrapper2 but currently it seems that it does not work.

I tried the tests here: http://eris.liralab.it/yarpdoc/rpc_ports.html and they are working fine, but if I do it with a simple yarp read & write it doesn't.

yarp write /w
yarp read /r /w
yarp read /r2
yarp connect /w /r tcp+log.in
it says-> Success: Added connection from /w to tcp+log.in://r2;
port /r2 says -> yarp: Receiving input from /w to /r2 using tcp+log.in

but data are not shown in the /r2 port (while if I simply do a connect /w /r2 it works)

Also I'm not able to use it with robotMotorGui or other tools using the remote_controlboard.

[paulfitz]

@barbalberto the log.in modifier is for logging inputs. Try:

yarp connect /r /r2 tcp+log.in

and you should see messages being received by /r echoed to /r2

For the question in the issue title: no, the logging mechanism knows nothing about the RpcClient/RpcServer classes, it is not specialized for those.

[barbalberto]

WHAT ?? Is that the way it works?
Is there another specific page about it? because the only pages I found:
http://wiki.icub.org/yarpdoc/yarp.html#yarp_forward
http://eris.liralab.it/yarpdoc/rpc_ports.html
really tells a whole different story!!
I don't want to be rude, but I think there is no way from those pages to understand that behaviour. We were 3 guys reading the instruction and none of us got it right!!

So the way I should read the command
yarp connect /port tcp+log.in://debug
is the one shown in the following picture?

Are the three versions
yarp connect /port /debug tcp+log.in
yarp connect /port tcp+log.in://debug
yarp connect tcp+log.in://port /debug
all the same?

And it should work like this, right?

If I use plain yarp read/write, it seems that the carrier is ignored because the leading [rpc] is missing in the output so it is not a good test.

If I try with the rpcClient/server test the result is different from the picture above

If the log.in would log the input messages then when I do
yarp connect /server /read tcp+log.in
I would expect to see just
<[rpc]> (COUNT 29) --> incoming message
and if I do
yarp connect /client /read tcp+log.in
I would expect to see
<[rpc]> (you said COUNT 29) --> incoming message

Instead, in the first case I get
<[rpc]> (COUNT 29) (you said COUNT 29)
which is [rpc] + input msg + reply.

If I do the vice-versa:
yarp connect /client /read tcp+log.in
I see nothing!

It seems that it only echoes input+reply and the timing is the time of the reply, therefore no reply means no log, and this is why it doesn't work on the client side I guess.

So the real thing looks like this

When the instruction says that you get the input from the source it is wrong, you get the output from the destination port.

So I wonder if there is also some log.out! If I try I get the same result as log.in while if I try with only tcp+log it gives an error (Failure: Outputs not allowed) Is log.out the same as log.in?

I'm fine with this usage, but the documentation should be far more clear.

[lornat75]

@barbalberto a quick test on my side.

yarp rpcserver /server
yarp rpc /server

yarp read /sniffer tcp+log.in://server

and

yarp read /sniffer

or

yarp connect /server /sniffer tcp+log.in

work as expected, /server relies all traffic (incoming message + reply) to /sniffer

[paulfitz]

@barbalberto my apologies that the documentation is confusing. Sorry you've all been losing time with this.

The way to read the command yarp connect /port tcp+log.in://debug would be:

• Make a connection from /port to /debug.
• Instead of sending regular data on that connection, send a log of inputs received.

For a streaming port, the log of inputs will be simple, just a copy of what is coming in to that port. If the port is replying to its inputs, the log will be tagged with [rpc] and include the reply corresponding to each input.

There is no log.out yet, but you're right yarp won't give you a clear warning/error if you try. I'll add an error message.

[paulfitz]

• give error if log.* is tried, where * != in
• improve documentation for log.in

[barbalberto]

Thanks Paul, sorry for my vent in the previous message.

Just one more question: dumping the data with the dataDumper using the code

        Stamp info;
        BufferedPort<T>::getEnvelope(info);
        sequenceNumber=info.getCount();

it always get -1 as a sequenceNumber while the timestamp look fine;
Is it a reading error or the sequence number is missing in the logging?
It will be useful to replay the data with the dataSetPlayer

[pattacini]

This is an expected behavior if the incoming messages do not contain the envelope.

[paulfitz]

I did some testing and the logging connection seems to correctly copy the envelope of incoming messages. If there is no envelope on incoming messages, it doesn't add one (hopefully info.isValid() should be false?). It could add one, would that be helpful?

[barbalberto]

Since it is used for logging purpose I think it would be nice to add one if not present.
Not everyone knows about envelope so it could be quite common that it is missing I guess.
I'll check what the controlBoardWrapper is doing and add if it is missing.

Thanks

[pattacini]

The data packet number is meaningful only when it refers to data transmitted along with the envelope in order to see whether we have a packet loss. Moreover, I deem a -1 useful to understand that the incoming messages are envelope-less.
I tend to keep things like that then.

[paulfitz]

Closing this issue. It feels like there is a remaining question about envelopes (maybe yarp should be adding one by default if the user doesn't?) but it is not specific to the log.in mechanism. Would welcome ideas on that in a separate issue.