Very Computer

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

Quote:> 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?

DS

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

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

jack - Grapevine/Richardson

Quote:> ... 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.

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

Quote:> 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.

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...