Re: ada sockets question

[Ted Dennison<dennison@telepath.com>]

In article <9i0p05$ic4$1@fang.dsto.defence.gov.au>, Vladimir Bednikov says...
>
>I am trying to transfer 32 lots of 2048 data samples which are in signed
>short int format. One way i did it was to create a string to hold each 
>individual 2048 samples and send it. This takes 32 seconds to send the 32
>blocks, I want it sent in less than one second.
>I tried to combine all 32 blocks of 2048 samples into one string and send it
>in one go but got a core dump when I tried to use the stream_listener example >to receive the data.
>Is there a max limit on the size of the packets that I can send?

A lot depends on whether you are using TCP or UDP.

UDP's maximum packet size is about 64K. If you use the "sockets" interface (as
practicaly everyone does), you are only allowed 8k. I believe TCP has this limit
as well, but since it is stream-oriented, it can just keep feeding in more data
until it is done (and so can you). If you send UDP more than the network's
"Maximum Transmission Unit" (usually a smidge under 1500 bytes) it will get
fragmented. The fragments will be reasembled properly on the other end, so no
worries there. However, if any part of that fragmented series of packets
experiences a problem, the whole damn thing has to be resent. TCP handles
"fragmenting" at its own level (it calls it "segmenting"), so that if something
goes wrong, only the individual packet (segment) with the problem needs to be
resent. TCP actually will do the resend too, whereas UDP just throws the data on
the floor and goes on. 

TCP has lots of timing issues. The thing to realize about TCP is that is was
designed to be efficient for lots of small transmissions (like might occur if
you are typing in a telnet connection). It can do "bulk" transmissions too, but
its helps to reconfigure a few things first. For instance, by default it likes
to delay data sends on the connection until it has an acknowlegement message
that it can piggyback the data onto. If no such message is forthcomming, there
can be a significant delay (usually 200ms or so) while it waits for one. Also,
if you send a lot of data before the recipient can get around to dealing with
it, there are a couple of different places the send can get blocked until the
recepient gets around to reading some of the data. (eg: you probably don't have
enough mbufs on your socket to store one entire transmission) There are ways to
configure things to minimize this, if you know what you are doing.

So you say that each block is taking one second to transmit? The fact that your
timing is such (large) round numbers to my mind is *very* suspcious. I would
guess you are running into a timer somewhere. As you can see, the network code
(especially TCP) is chock full of timers. If you are serious about finding the
cause of the slowness, I'd say the best thing to do would be to get a network
monitor and connect it to the network segment one of the machines is running on.
Odds are the kind folks who keep your network running have one, and may even
show you how to use it (for a suitable inducement, of course). It might also pay
to get a good TCP/IP reference. "TCP/IP Illustrated" is wonderful (volume 2
includes most of the sources for the stack!) but costs a little over $130 (US)
for the two-volume set.

There is a *lot* that can go wrong with network transmissions (particularly on a
large busy network). Trying to blindly blame throughput problems on anything
non-network related, when in fact you haven't the foggiest clue what is going
wrong, seems more than a bit premature.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com