[tg] Traffic Generator: UTP server question

[Andro Galinovic (ZG/ETK/DR)]

Hi Barbara.
Hugues from info.fundp.ac.be also suggested "-f". As I said to Hugues
"-f" works, but I still have to change the code and decrease
the timeout (prot_dgram.c line 319):

else   {

    /* Nothing more to read right    */

    /* now.                */

    gettimeofday(endtout, (struct timezone *)NULL);

    endtout->tv_sec+=30;

    break;

 }


and recompile the program which ends in multiple warnings and an error (
tg.y:271: error: conflicting types for 'malloc' ).
But I can fix that. The error I mean, by commenting line 271 in the file
tg.y ( //extern char *malloc(); ).
Warnings (see attachment ) still remain but I suppose that's OK :)

I just think that's inconvenient that the server doesn't stop when the
client stops, because if a have a script that runs tg more then ones
with the same configuration file (same address, port number,....) or I
rerun that script, that it can be a problem. I suppose a "end" UDP
message would do the trick.

In my case manually kill the tg process isn't a option, everything has
to be automatic.

bye


                                                                       
        Andro


Barbara Denny wrote:
> hi,
>
> Hum....you might have found a bug. I've never waited
> for tg to "timeout" on the receive side of a udp
> stream. I'll need to look at that.
>
> I have noticed that the behavior of tg has changed
> slightly with linux. Sending a TERM or INT signal
> to the process should cause the process to die and
> the log to be written out. It doesn't do that and
> I can't see any "bug" in the software so I need to
> do some more debugging. (If anyone else has had
> problems with redirecting a signal to a new
> handler under linux, let me know. That appears to
> be the problem here).
>
> As a work around I suggest the following, use the
> -f switch (for flush) when you start your client
> so the data will not be buffered. Then manually
> kill the tg process on the receive side with a
> USR1 or kill signal after the send side is done.
>
> Hope this "solution" is satisfactory for you.
>
> barbara
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compile.log
Type: text/x-log
Size: 6574 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/tg/attachments/20060731/f898459a/compile.bin