[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

# Re: maximum message size

- To: Richard Baldwin <baldwin@pgc.nrcan.gc.ca>
- Subject: Re: maximum message size
- From: "Dr. Kent Lindquist (Seismologist)" <kent@giseis.alaska.edu>
- Date: Mon, 06 Mar 2000 13:11:48 -0900
- Cc: earthw-list@nmt.edu

    Richard Baldwin wrote:
    >
    > Hello all,
    >
    > A simple question:
    >
    >     Is there a maximum allowable size for an earthworm message, regardless of
    >     the MSG_LOGO? Such a beast would be very handy for allocating buffers that
    >     could handle any possible message that might come in, avoiding altogether
    >     the error GET_TOBIG.
    >
    > Thanks,
    >
    > Richard

    The other way to go is to consider dynamic memory allocation, i.e.
    allocating the amount of memory you need for each message as it comes
    in. This has become a fairly standard technique. Dynamic memory
    allocation offers a number of advantages, for example you don't risk
    crashes or data loss if a message comes in that is too big for a
    pre-allocated buffer. This makes a more robust system: it's not good to
    have software that crashes if it gets data it didn't expect. Of course,
    it is possible with correct handling of a GET_TOOBIG return code that
    the software will merely lose data rather than crash. However, fully
    dynamic memory allocation can avoid even this lesser evil of data loss.
    Having a parameter that sets the maximum allowable size of a message is
    not ideal because that parameter either has to be compiled in (through a
    .h file or whatever) or specified in a parameter file. The first option
    permanently removes flexibility from the software package by arbitrarily
    and unnecessarily limiting the packet-sizes allowable to the end user.
    The parameter-file option reinstates that flexibility, though putting
    maximum packet size in the parameter file in essence makes the end user
    partially responsible for memory allocation. The software engineer
    should take full responsibility for this level of detail, though, rather
    than leaving part of the task to the user or leaving the system with
    restricted functionality. Therefore I'd recommend looking into removing
    all traces of statically allocated buffers and replacing them with fully
    dynamic allocation mechanisms.

    Good luck,
    Kent

    --
    Dr. Kent Lindquist, Seismologist
    Geophysical Institute                Ph. (907) 474-5161
    University of Alaska                 Fax (907) 474-5618
    Fairbanks, AK 99775-7320

    http://giseis.alaska.edu/Seis/Input/kent/kent.html

- Prev by Date: Earthworm V4.1 Patch A
- Next by Date: Earthworm Status Report
- Prev by thread: Earthworm V4.1 Patch A
- Next by thread: Earthworm Status Report
- Index(es):
  - Date
  - Thread