Controlling rate of tcp/ip data transmission

Not sure if this is a 'networking' question or what exactly....

I need to be able to control the 'rate' at which I send data on a slow
speed link. It's an ethernet port... but the device that is connected
is a slow speed device. I don't know of an 'offical' way to control the
rate... i'm just using socket sendto and adding a delay between packets
of data. I know that I send 'x' bytes in 'y' secods so I can come up with
my kbs transfer rate. The engineers looking at the line say that the data
is 'bursty' which it is... I've changed my code to send 1/4 the size of
the data packet with 1/4 the wait between packets. The data is less
'bursty' now.... and I'm getting about the same trasnfer rate but I've got
4x as much overhead on the control packets I'm sending...

Is there a better way to control how fast data goes over an
ethernet port than the send/wait/send/wait/send/wait approach
I've come up with?

--
D.A.M. - Mothers Against Dyslexia

see http://www.jacksnodgrass.com for my contact info.

jack - Grapevine/Richardson

On Jul 11, 12:48 pm, Jack Snodgrass <jacks_temp_id_ind...@verizon.net>
wrote:

> I need to be able to control the 'rate' at which I send data on a slow
> speed link. It's an ethernet port... but the device that is connected
> is a slow speed device. I don't know of an 'offical' way to control the
> rate... i'm just using socket sendto and adding a delay between packets
> of data. I know that I send 'x' bytes in 'y' secods so I can come up with
> my kbs transfer rate. The engineers looking at the line say that the data
> is 'bursty' which it is... I've changed my code to send 1/4 the size of
> the data packet with 1/4 the wait between packets. The data is less
> 'bursty' now.... and I'm getting about the same trasnfer rate but I've got
> 4x as much overhead on the control packets I'm sending...
>
> Is there a better way to control how fast data goes over an
> ethernet port than the send/wait/send/wait/send/wait approach
> I've come up with?

Are you using TCP or UDP? You say "packets", so I'm guessing you mean
UDP.

DS

On Wed, 11 Jul 2007 15:33:03 -0700, David Schwartz wrote:

> On Jul 11, 12:48 pm, Jack Snodgrass <jacks_temp_id_ind...@verizon.net>
> wrote:
>
>> I need to be able to control the 'rate' at which I send data on a slow
>> speed link. It's an ethernet port... but the device that is connected
>> is a slow speed device. I don't know of an 'offical' way to control the
>> rate... i'm just using socket sendto and adding a delay between packets
>> of data. I know that I send 'x' bytes in 'y' secods so I can come up
>> with my kbs transfer rate. The engineers looking at the line say that
>> the data is 'bursty' which it is... I've changed my code to send 1/4
>> the size of the data packet with 1/4 the wait between packets. The data
>> is less 'bursty' now.... and I'm getting about the same trasnfer rate
>> but I've got 4x as much overhead on the control packets I'm sending...
>>
>> Is there a better way to control how fast data goes over an ethernet
>> port than the send/wait/send/wait/send/wait approach I've come up with?
>
> Are you using TCP or UDP? You say "packets", so I'm guessing you mean
> UDP.
>
> DS

.... yes... UDP... does it matter? It's also a one-way connection.. the
receiver has 0 TX and the sender has 0 RX on the connection.

--
D.A.M. - Mothers Against Dyslexia

see http://www.jacksnodgrass.com for my contact info.

jack - Grapevine/Richardson

On Jul 11, 4:03 pm, Jack Snodgrass

> ... yes... UDP... does it matter? It's also a one-way connection..
> the receiver has 0 TX and the sender has 0 RX on the connection.

It matters tremendously. The answer to your question is, use TCP. TCP
was developed precisely to solve problems just like this. UDP was
designed for applications that want to do this themselves.

Each datagram will be sent more or less when you call 'sendmsg'. If
you are sending a large datagram over a fast link, the fragments will
probably be sent back-to-back.

UDP makes the application responsible for transmit pacing, duplicate
detection, lost datagram detection, proper datagram selection, and
quite a few more things that TCP does automatically.

Transferring large amounts of data over UDP is very tricky to get
right, especially with a slow link somewhere in the middle.

DS

David Schwartz <(E-Mail Removed)> wrote:
> On Jul 11, 4:03 pm, Jack Snodgrass

> > ... yes... UDP... does it matter? It's also a one-way connection..
> > the receiver has 0 TX and the sender has 0 RX on the connection.

Do you mean to imply that it is not physically possible for the
receiver to send anything to the sender?

> It matters tremendously. The answer to your question is, use
> TCP. TCP was developed precisely to solve problems just like
> this. UDP was designed for applications that want to do this
> themselves.

And just in case it wasn't obvious, where "this" is "flow-control."
In the case of TCP, it is a window-based flow control, where the
receiver advertises a certain window to the sender, the sender send's
up to a window's-worth of data before he must stop and wait for a
window update from the receiver.

If indeed you cannot have anything transmitted back from the receiver
to the sender you cannot use TCP, and some sort of rate-based pacing
along the lines of what you are using is what you can use. What sort
of link-rates are we talking about on either end here? What sort of
rate can the receiver tolerate? A few more details about the setup
might help us postulate some other possibilities.

The comment about the size of the sends you make via UDP possibly
leading to short bursts of IP datagram fragments is a good one to
heed.

rick jones
--
The computing industry isn't as much a game of "Follow The Leader" as
it is one of "Ring Around the Rosy" or perhaps "Duck Duck Goose."
- Rick Jones
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...