Movatterモバイル変換


[0]ホーム

URL:


[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

UNKNOWN
NETWORK WORKING GROUP                     Dave WaldenREQUEST  COMMENTS #297                    BBNNIC #8485                                 1/31/72Categories: C or maybe DUpdates: noneObsoletes: noneTIP Message Buffers     We have recently heard some groaning about the size of the TIP'smessage buffers.  While we realize these aren't as big as some Hostsmight desire, they aren't as small as the intensity of the groanssuggest either.     Let's first consider messages going from a TIP to another Host.The buffers have the following sizes:     device numbers           buffer size (in 8 bit characters)         1-2                       64         3-16                      32        17-41                      16        42-62                      8         63                        6The TIP user has the option of having his messages sent 1) everycharacter, 2) on line feeds and/or com's, 3) every nth character, or4) the OR of 2) and 3). Selecting to have messages sent every largenumber of characters, say 100, will result in the TIP sending thelongest messages it can for a given device.  Hosts which don't like toreceive very short messages might advise users accessing them from aTIP to set the TIP's parameters to use the maximum length buffer.     Now let's consider messages going from another Host to a TIP.The buffers have the following sizes:     device numbers           buffer size (in 8 bit characters)        1                          96        2                          64        3                          48       4-17                        24      18-35                        16      36-63                         8                                                                [Page 1]

The TIP double buffers its terminal output.  Thus, when a TIP terminalmakes a connection to a Host, the TIP sends off an allocation ofbetween 8 and 96 characters, depending on the terminals device number,and when a message comes using up the allocation, the TIP immediatelysends another allocation for the same number of characters while itprints the first buffer.     For traffic both to and from the TIP, lower numbered devices havebigger buffers.  Therefore, users of line oriented systems, as well asusers of higher speed devices, should try to come in through the lowernumbered ports on the TIP's multi-line controller, if possible.     The sizes of the TIP's message buffers and the number of eachsize are not permanently fixed and can be changed if a betterdistribution is suggested.  We didn't know what size buffers toprovide so we have provided a variety, What is fairly fixed is thetotal amount of buffer space: two output buffers and one input bufferfor each of 63 devices must come out of this total buffer space.     The answer to your question "Why not dynamically allocate buffersat run time?" is: It is a complicated job to do that.  It requiresmemory compactions, a mechanism to reclaim space from current userswhen a new user comes on, etc.  Our guess is that the code todynamically allocate buffers at run time would reduce the total spaceavailable for buffers by about one-fifth.       [ This RFC was put into machine readable form for entry ]       [ into the online RFC archives by BBN Corp. under the   ]       [ direction of Alex McKenzie.                   12/96   ]                                                                [Page 2]

[8]ページ先頭

©2009-2025 Movatter.jp