Re: Controlling rate of tcp/ip data transmission

David Schwartz <davids@xxxxxxxxxxxxx> 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...
.

Relevant Pages

  • Re: Neutral Format as a Coupling reduction idea that doesnt work.
    ... There are potentially unlimited and unexpected side effects for both sender and receiver. ... That definition defines the semantics of the just the data packet. ... That represents a solution level coupling but at least it is very narrowly focused on the message definition rather than what each side does with the information. ...
    (comp.object)
  • Re: Question: Designing a protocol over TCP
    ... Your receivecall will be completed as soon as an incoming TCP segment has ... Once your recv() call has been completed, ... sender and receiver side makes it possible for the receiver side to always ... complete recvcalls with exactly the number of bytes the sender has sent. ...
    (microsoft.public.win32.programmer.networks)
  • Re: PostMessage and unprocessed messages
    ... The sender has no way to know when to delete the message, so making it the owner has no ... Since the receiver would have no way to know the message is deleted, ... collection, note that as long as something is in the queue, it is owned by the queue ... so adding memory management complexity to the ...
    (microsoft.public.vc.mfc)
  • Re: PostMessage and unprocessed messages
    ... No need to keep a linked list, because the PostMessage queue is already ... The sender has no way to know when to delete the message, ... Since the receiver would have no way to know the message is deleted, ... so adding memory management complexity to the ...
    (microsoft.public.vc.mfc)
  • Re: PostMessage and unprocessed messages
    ... No need to keep a linked list, because the PostMessage queue is already ... The sender has no way to know when to delete the message, ... Since the receiver would have no way to know the message is deleted, ... so adding memory management complexity to the ...
    (microsoft.public.vc.mfc)