ok, so packet size represents a very interesting nexus of problems. i'll
try to be brief:
1) there is a scale issue related to resource utilization at the server.
if the server is
supporting 30,000 connections (say, an IM application), then you want to
limit
the amount of memory each connection consumes. large packets have a way
of concentrating resources, in both kernel and app spaces, in a way that the
app has no direct control over. so app deployments may want to limit packet
size as a way of preventing denial of service, intentional or not.
2) large packets on a connection limit the traffic on the connection, as the
connection represents a choke point, traffic is necessarily serialized.
the result
is, multiple threads using a connection, say in a ui or web application, can
unduly interfere with each other.
3) impl detail: when the packet is assembled by requiring the allocation
of a single
large buffer (as is the case right now), the allocation of a single
large buffer often
has a bad effect on a heap, garbage collected or not. heaps do not at
all perform
well when large buffer allocation is going on. this can cause
catastrophic heap
thrashing and inefficient memory utilization in a system which otherwise
should
have enough resources to do the job. (i have a plan sketched out for a
composite
buffer object which is actually implemented using many small buffers (8k
each),
which reduces the heap load. the small buffers might be drawn from a buffer
pool shared between all connections and thus no permanently assigned to any
single connection. and their allocation would be turbo fast, and they
could be
allocated using a direct mapping technique which would eliminate data
copying
in the network stack.)
in your example, video or audio streaming, certainly the data should be
chunked
and streamed that way. it means you can start playing an audio stream as
soon
as you have a few buffers full. also etch lets you start a call
asynchronously and
then request notification on receiving the response or even have two (or
more)
calls outstanding at the same time (double buffering!). the perf example
demonstrates this technique in the asyncAdd test.
example chunky loop:
string id = server.openFile( "sound.wav" );
try
{
byte[] buf;
while ((buf = server.readFile( id, 8192 )).length > 0)
processData( buf );
}
finally
{
server.closeFile( id );
}
the server is then actually free to load the whole file into a memory
cache or even
memory map it, or just hold a file handle open and stream it. the data
might come
from an actual file, database, imap connection, web connection, whatever.
scott out
Suresh Kumar wrote:
Hello Scott,
Thanks for the detailed response.
I do understand that the underlying tranport will impose some limit on the packet size. However, my question to you is what kind of limitation does Etch introduce on packet size? Or is the packet size completely dependent on the underlying transport?
I am specifically looking at a use case where one needs to transfer streaming data (video, file transfer etc..). Will Etch support such a use case? If not, is it possible to extend Etch to support streaming.
Thanks & Best Regards,
Suresh
_______________________________________________
Etch mailing list
Etch@developer.cisco.com
_______________________________________________
Etch mailing list
Etch@developer.cisco.com
Attachment not added (content type not allowed): "sccomer.vcf"
Cisco Unified Application Environment Developer Forums 
