Your patch is functionnally OK.
Nevertheless, I've just made some modifications to your patch
and attached mine to the tracker.

It is in an attempt to:

1) Make the change more "local".
   It modifies 4 files instead of 7.

2) Avoid adding parameters to
   data_receiver and stream_sender
   because I think its not as generic as we
   should aim at.

The idea is to keep the data_address I/F we had
before but make tsp_consumer.c handle the
"default missing parts" in our case add
the missing "hostname" to "data_address"
before calling TSP_data_receiver_create.

I remove the <sys/param> include for
MAXHOSTNAMELEN and use
TSP_MAXHOSTNAMELEN, the less we depend on
system includes the less we got in portability trouble.

We may further use CMake in order
to link TSP_MAXHOSTNAMELEN to
MAXHOSTNAMELEN if it is defined.

Would you try my patch in order to see if it suits
your needs?

Tests are OK on my side even if I need to test
it on real-networked configuration I do not have
at home.

When we are OK with the patch I think
we will (you/or me) check in CVS as soon as
other TSP consumer implementation
(java, ruby at least) are ready to handle the new
TSP data channel URL scheme.

I assigned the patch to you since you began this,
and you are TSP developer :))


PS: my patch is a directory diff because
    Savannah CVS seems offline, should be OK though...
    I hope :))

(file #12365)

I'm OK with your point
and I will just do that unless you
want to do it and provide a patch?

Thanks a lot
for this lenghtly reply and fine analysis.

And please excuse me for my doubt about network config,
I had made tsp_check_host_and_ip because most TSP
connection problem were a consequence of buggy/weird config.

The data_address contained in
answer_sample_init (which is the reply to request_sample_init)
effectively includes the @IP + port.

This was done on purpose because we wanted
to separate
command channel handling (ONC-RPC, XML-RPC, etc...)
from
data channel handling (currently socket opening on "data_address"

It may seems weird but we can imagine that even if
you use "tsp_command.yourlan.nl" for command channel
(sending TSP_request_xxx and receiving TSP_answer_xxx)
you "MAY" perfectly get the data channel stream from
"tsp_data.yourlan.nl" if the answer_sample_init answers
this way. A first use case may be if your TSP provider
box has several network I/F and you may want to accept
command on eth0 and send sample on eth1.

This is not possible with current TSP implementation
but I would like to keep this option open.
In fact the data_address of TSP data channel has been
thought as a kind of "url" which may be extended for
other kind of data channel communication medium
(shared memory, messgae queue, SSL socket etc...)

However you are perfectly right, since we don't use those
"fancy possible features" today we should not
pay for what we don't use.

I will try to modify the code as you told,
only send the port. Then use the same "name" we
use for command channel in data channel. This creates
a link between the two channels but it seems
reasonnable for our current usage.

As a side-note we did a gethostname followed by gethostbyname
on provider side on provider side since we had no mean
to know the @IP address that was used by consumer side
to reach us.

Simple procedure to repeat bug:
start tsp_stub_server
start tsp_stdout_client (different terminal)
All ok.
sudo ifdown eth0/eth1/whatever network i/f you have
start tsp_stdout_client (different terminal)
#=========================================================#
# Launching <stdout_client> for printing symbols received #
#=========================================================#
/opt/tsp/bin/tsp_stdout_client: Using provider URL <localhost>
/opt/tsp/bin/tsp_stdout_client: Asking for:
         <5> samples (0 => INFINITE loop)
      of <1> TSP symbols
      at period <1>.
/opt/tsp/bin/tsp_stdout_client: Asking for 1 symbols
   symbol <0> is <t>
  ERROR||/home/rhdv/src/tsp-0.8.2-build/RPM/BUILD/tsp-0.8.2-Source/src/core/driver/tsp_stream_receiver.c##TSP_stream_receiver_create##184: pb connecting to socket
  ERROR||/home/rhdv/src/tsp-0.8.2-build/RPM/BUILD/tsp-0.8.2-Source/src/core/driver/tsp_data_receiver.c##TSP_data_receiver_create##140: TSP_stream_receiver_create failed
  ERROR||/home/rhdv/src/tsp-0.8.2-build/RPM/BUILD/tsp-0.8.2-Source/src/core/driver/tsp_consumer.c##TSP_consumer_request_sample_init##1153: Unable to create data receiver
tsp_stdout_client: /home/rhdv/src/tsp-0.8.2-build/RPM/BUILD/tsp-0.8.2-Source/src/core/driver/tsp_consumer.c:1232: TSP_consumer_read_sample: Assertion `otsp->sample_fifo!=0' failed.

Program received signal SIGABRT, Aborted.
[Switching to Thread -1208440128 (LWP 4496)]
0x0012e402 in __kernel_vsyscall ()
(gdb) where
#0  0x0012e402 in __kernel_vsyscall ()
#1  0x484ecd40 in raise () from /lib/libc.so.6
#2  0x484ee591 in abort () from /lib/libc.so.6
#3  0x484e638b in __assert_fail () from /lib/libc.so.6
#4  0x08052129 in TSP_consumer_read_sample (provider=0x93bc990, sample=0xbfc84094, new_sample=0xbfc840ac)
    at /home/rhdv/src/tsp-0.8.2-build/RPM/BUILD/tsp-0.8.2-Source/src/core/driver/tsp_consumer.c:1232
#5  0x0804c79a in main (argc=1, argv=0x93ba018)
    at /home/rhdv/src/tsp-0.8.2-build/RPM/BUILD/tsp-0.8.2-Source/src/consumers/stdout/client_stdout.c:332

Robert,

Could you please

1) execute tsp_check_host_and_ip
   and post the result here
   (when you are in the buggy config state)

2) post the excerpt of your /etc/hosts file
   containing the definition
   @IP name alias for localhost
   @IP name alias for the "real" hostname
   (the name you get with /bin/hostname

Some Fedora/Redhat distribution have the
bad idea to associate @IP w.x.y.z with localhost
instead of 127.0.0.1.

So that we "gethostbyname(localhost)" to get @IP and get
w.x.y.z instead of 127.0.0.1, then since
w.x.y.z you get an error which leads to the core dump.

> Of course first of all the client should not dump core.

You are right the core dump is really bad and we
must fix it.

regarding:

> Second of all the client should not attempt to connect to
> anything other than localhost.

You may be right and we should be currently
doing just that (unless you use -u TSP_URL)
Nevertheless, in the end we call
clnt_create("localhost" etc...)
which may be got trapped into the wrong gethostbyname behavior.

I should check whether if the core dump occurs
in the call or outside the call.