The channel that you configure in the config file is then used in the scenario. If you configured "channel-1" in your config file, you will use "<send channel="channel-1">" in your scenario.

This is not possible. You will have to run several Seagull in parallel for that. I will see what we can do for a future release.

• A traffic scenario (sequence of send/receive/wait-ms) is defined.
• The traffic scenario is multiplied, following the "call-rate" instruction. 100 calls/second call rate will start 100 parallel scenarios for each second.
• Other kind of scenarios (init, default, abort) can also be defined. Those scenarios are not "multiplied" following the call rate. See doc for more details on those.

By default, the call will be stuck forever. You need to activate the call-timeout to instruct Seagull to close "hanged" calls. If a call is active beyond the call-timeout-ms value, the call will time out and Seagull will close the call by using the <abort> section of the scenario if it exists.

The message you see is because Seagull got an "EAGAIN" error from the TCP protocol stack when trying to send his message. This EAGAIN error occurs when Seagull cannot send anymore data (like when TCP buffer full): the TCP stack asks the application (Seagull) to try again later. But this mechanism (which can be called "flow control") is not implemented in Seagull.

Looking at the possible causes, this might be because the remote application (to which Seagull talks to) doesn't read data quick enough, which causes TCP stack queues on which Seagull is relying to be overloaded.

Also, you must be aware that when you change the call rate, the max-send and max-receive as well as maybe max-simultaneous-calls parameters must be changed accordingly (see http://gull.sourceforge.net/doc/core.html#ref_traffic_param for values)

Yes, Seagull runs and runs. Judge for yourself: