Subject: Re: JPEG in INVITE

From: [email-masked]
Date: Fri, 24 Dec 1999 12:24:37 +0530

Hi,
my answers are inline marked with Arjun>

Just curious. I would like to know why you would allocate a buffer of 64K.
You
can perform dynamic allocations or use collections and the size of the
message
becomes immaterial.

Arjun> Well, if say its a TCP message, I guess I could do incremental
reads,
Arjun> However. if its a UDP message of size X, I cant readn bytes first
with
Arjun> the first recvfrom and expect the next X-n bytes to be passed in the
next
Arjun> recvfrom - the extra data is lost (There is something called
SOCK_SEQPACKET
Arjun> which is not standard). So I dont know how you can solve this
problem with dynamic
Arjun> allocation  - you either read the full packet at one go, or lose the
rest of the data.
Arjun> You can chop off to the correct size, after you do the UDP read, not
before.

> Then the only way for a person who really does not want to allocate 64k
is
> to read from the n/w till he gets a content-length, figure out
> the size and then read the rest of the body. this is kludgy at best.

I would like to know why this is kludgy? To me, it's the only technique
that
makes sense. Unless you know the length, the hint of which is provied by
the
Content-Length header,  there is no other way to approximate the length of
the
body. If I am missing something here, let me know.

Arjun> Well its like this. If content length was something like a TPKT
header
Arjun> which is bound to occur at the start, its a neat way. But now we are
Arjun> saying that this header can occur anywhere in the header space, you
cannot
Arjun> assume its position at a location. So that means, read some chunk of
data (you
Arjun> might even land up reading one 3-4 headers and half another header,
depending on
Arjun> size of headers), now figure out where in the read buffer is
content-length, then
Arjun> read till end of the headers (there can be more headers after
CLength) etc. Of course
Arjun> there are cases when you can possibly read half a contentlength
header (as you are guessing
Arjun> on input header size) and have to  correlate.
Arjun> So basically,if space is a constraint for you,you are left with no
easy way to figure
Arjun> out message length besides groping where in the header space is the
elusive Content length.
Arjun> which, imho, is quite kludgy.

Merry Chrismas and Happy Millenium to all!

Arjun> And the same to you, and the rest of the folks here too !

 --
 Arjun Roychowdhury @ Hughes Software Systems

---

From: Bobby Sardana <[email-masked]>
Date: Sat, 25 Dec 1999 18:27:07 -0600

Greetings:

For UDP, the algorithm I have in mind is as follows:

a. Allocate  sizes that are MTU based.
b. Perform "recvfrom" based on MTU sizes only. MTU, normally, for internet
backbone is 1500.
c. If sequencing is performed, then perform other reads.

Obviously, sequencing would require co-ordination between server and the
client. So essentially, the client and the server know what is the sequence
and how many packets (in multiples of MTU) to read and transport.

Bobby Sardana.
[email-masked]