Reduce or disable the TCP buffers - TCP-IP

This is a discussion on Reduce or disable the TCP buffers - TCP-IP ; Hi all I have a problem with TCP buffers. First let me explain you about my application. We have a electronic board which serves Serial ports on LAN. i.e. The LAN users can access the serial ports on this board ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Reduce or disable the TCP buffers

  1. Reduce or disable the TCP buffers

    Hi all

    I have a problem with TCP buffers.

    First let me explain you about my application.

    We have a electronic board which serves Serial ports on LAN.

    i.e. The LAN users can access the serial ports on this board as if
    they are in their PC. The board is accessible through ethernet to all
    the PC's.

    Now that when two PC's are communicating using the serial ports on
    this board using XON/XOFF flow control and when the receiver end is
    pausing the reception the sender is still transmitting, whereas the
    transmitter also should stop sending the data.

    Actually we could figure out the problem, i.e. the buffering is taking
    place in the TCP protocol, so the flow control is not getting
    triggered.
    Is there any way to reduce the TCP buffers, We have already tried the
    setsockopt function to reduce the RECV and SEND buffers, but still the
    buffering is taking place and the problem persists.

    Is there any other alternate way to disable the TCP buffers other than
    setsockopt.

  2. Re: Reduce or disable the TCP buffers

    In article
    <08bc2741-21f3-4c9d-b71c-7c03b015e8d6@s12g2000prg.googlegroups.com>,
    karthikphaninder@gmail.com wrote:

    > Hi all
    >
    > I have a problem with TCP buffers.
    >
    > First let me explain you about my application.
    >
    > We have a electronic board which serves Serial ports on LAN.
    >
    > i.e. The LAN users can access the serial ports on this board as if
    > they are in their PC. The board is accessible through ethernet to all
    > the PC's.
    >
    > Now that when two PC's are communicating using the serial ports on
    > this board using XON/XOFF flow control and when the receiver end is
    > pausing the reception the sender is still transmitting, whereas the
    > transmitter also should stop sending the data.
    >
    > Actually we could figure out the problem, i.e. the buffering is taking
    > place in the TCP protocol, so the flow control is not getting
    > triggered.
    > Is there any way to reduce the TCP buffers, We have already tried the
    > setsockopt function to reduce the RECV and SEND buffers, but still the
    > buffering is taking place and the problem persists.
    >
    > Is there any other alternate way to disable the TCP buffers other than
    > setsockopt.


    Why do you need to do this? What's wrong with the transmitter
    continuing to send, as long as the board has buffer space for it?

    When the buffer fills up the receiver will close the TCP window, and
    then the transmitter will stop.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  3. Re: Reduce or disable the TCP buffers

    On Jan 10, 8:54*pm, Barry Margolin wrote:
    > In article
    > <08bc2741-21f3-4c9d-b71c-7c03b015e...@s12g2000prg.googlegroups.com>,
    >
    >
    >
    >
    >
    > *karthikphanin...@gmail.com wrote:
    > > Hi all

    >
    > > I have a problem with TCP buffers.

    >
    > > First let me explain you about my application.

    >
    > > We have a electronic board which serves Serial ports on LAN.

    >
    > > i.e. The LAN users can access the serial ports on this board as if
    > > they are in their PC. The board is accessible through ethernet to all
    > > the PC's.

    >
    > > Now that when two PC's are communicating using the serial ports on
    > > this board using XON/XOFF flow control and when the receiver end is
    > > pausing the reception the sender is still transmitting, whereas the
    > > transmitter also should stop sending the data.

    >
    > > Actually we could figure out the problem, i.e. the buffering is taking
    > > place in the TCP protocol, so the flow control is not getting
    > > triggered.
    > > Is there any way to reduce the TCP buffers, We have already tried the
    > > setsockopt function to reduce the RECV and SEND buffers, but still the
    > > buffering is taking place and the problem persists.

    >
    > > Is there any other alternate way to disable the TCP buffers other than
    > > setsockopt.

    >
    > Why do you need to do this? *What's wrong with the transmitter
    > continuing to send, as long as the board has buffer space for it?
    >
    > When the buffer fills up the receiver will close the TCP window, and
    > then the transmitter will stop.



    His problem is that the serial port flow control (the XON/XOFF) is
    happening at the PC, and by the time the PC processes the XOFF from
    the device, a bunch of stuff is already queued up in TCP buffers and
    elsewhere.

    This is actually a pretty common problem. USB serial port dongles
    suffer from it as well, and devices that have relatively tight timing
    requirements tend to break badly.

    To the OP:

    There's not really a good way to fix this at the TCP level, there are
    just too many places that might decide to do some unexpected
    buffering. What you need to do is get flow control working at the
    serial port on the network, and *not* at your PC. I'm guessing that
    you implemented XON/XOFF in your application, rather than setting the
    serial port (aka "COMx", assuming Windows) to do it for you. Assuming
    that this device presents as a normal serial port to the application
    (IOW "COMx"), then selecting that mode, or perhaps switching to
    hardware flow control, should move that boundary out to near the
    device.

    Alternatively, the LAN serial port device, may have some protocol for
    interrogating how much data it has buffered, you might be able to use
    that, although that's likely to be ugly.


  4. Re: Reduce or disable the TCP buffers

    Hi,

    Thanks immensely for your resoponces.

    Yes. There is nothing wrong in buffering the data by TCP buffers,
    but I want to simulate the exact serial communication where
    the transmission will be stopped if the receiver pauses reception.

    We did not implement any flow-control at application level.
    We are using the Teratermpro application.

    We have implemented flow-control at the box where the serial ports
    exists.

    PC1 is sending data through serial port (Port-1) of the box sitting on
    the network,
    which is connected to Port2 of the same box using null modem cable.
    PC2 is receiving data through Port-2. {Port-1 is virtualized in PC1
    and Port-2 is virtualized in PC-2}.

    It is observed that the Port 2's receive buffers never reaches it's
    trigger level because the data is getting
    buffered at the TCP socket of PC2. This is the reason why we are
    thinking of finding a way to reduce the buffer sizes
    of TCP protocol.

    So, Is there a way to reduce the TCP buffer size????

    Once again I thank you all for discussing the problem.
    Thank You.




    On Jan 11, 8:50*am, "robertwess...@yahoo.com"
    wrote:
    > On Jan 10, 8:54*pm, Barry Margolin wrote:
    >
    >
    >
    >
    >
    > > In article
    > > <08bc2741-21f3-4c9d-b71c-7c03b015e...@s12g2000prg.googlegroups.com>,

    >
    > > *karthikphanin...@gmail.com wrote:
    > > > Hi all

    >
    > > > I have a problem with TCP buffers.

    >
    > > > First let me explain you about my application.

    >
    > > > We have a electronic board which serves Serial ports on LAN.

    >
    > > > i.e. The LAN users can access the serial ports on this board as if
    > > > they are in their PC. The board is accessible through ethernet to all
    > > > the PC's.

    >
    > > > Now that when two PC's are communicating using the serial ports on
    > > > this board using XON/XOFF flow control and when the receiver end is
    > > > pausing the reception the sender is still transmitting, whereas the
    > > > transmitter also should stop sending the data.

    >
    > > > Actually we could figure out the problem, i.e. the buffering is taking
    > > > place in the TCP protocol, so the flow control is not getting
    > > > triggered.
    > > > Is there any way to reduce the TCP buffers, We have already tried the
    > > > setsockopt function to reduce the RECV and SEND buffers, but still the
    > > > buffering is taking place and the problem persists.

    >
    > > > Is there any other alternate way to disable the TCP buffers other than
    > > > setsockopt.

    >
    > > Why do you need to do this? *What's wrong with the transmitter
    > > continuing to send, as long as the board has buffer space for it?

    >
    > > When the buffer fills up the receiver will close the TCP window, and
    > > then the transmitter will stop.

    >
    > His problem is that the serial port flow control (the XON/XOFF) is
    > happening at the PC, and by the time the PC processes the XOFF from
    > the device, a bunch of stuff is already queued up in TCP buffers and
    > elsewhere.
    >
    > This is actually a pretty common problem. *USB serial port dongles
    > suffer from it as well, and devices that have relatively tight timing
    > requirements tend to break badly.
    >
    > To the OP:
    >
    > There's not really a good way to fix this at the TCP level, there are
    > just too many places that might decide to do some unexpected
    > buffering. *What you need to do is get flow control working at the
    > serial port on the network, and *not* at your PC. *I'm guessing that
    > you implemented XON/XOFF in your application, rather than setting the
    > serial port (aka "COMx", assuming Windows) to do it for you. *Assuming
    > that this device presents as a normal serial port to the application
    > (IOW "COMx"), then selecting that mode, or perhaps switching to
    > hardware flow control, should move that boundary out to near the
    > device.
    >
    > Alternatively, the LAN serial port device, may have some protocol for
    > interrogating how much data it has buffered, you might be able to use
    > that, although that's likely to be ugly.- Hide quoted text -
    >
    > - Show quoted text -




  5. Re: Reduce or disable the TCP buffers

    On Jan 11, 7:30*am, karthikphanin...@gmail.com wrote:
    > Hi,
    >
    > Thanks immensely for your resoponces.
    >
    > Yes. There is nothing wrong in buffering the data by TCP buffers,
    > but I want to simulate the exact serial communication where
    > the transmission will be stopped if the receiver pauses reception.
    >
    > We did not implement any flow-control at application level.
    > We are using the Teratermpro application.
    >
    > We have implemented flow-control at the box where the serial ports
    > exists.
    >
    > PC1 is sending data through serial port (Port-1) of the box sitting on
    > the network,
    > which is connected to Port2 of the same box using null modem cable.
    > PC2 is receiving data through Port-2. {Port-1 is virtualized in PC1
    > and Port-2 is virtualized in PC-2}.
    >
    > It is observed that the Port 2's receive buffers never reaches it's
    > trigger level because the data is getting
    > buffered at the TCP socket of PC2. This is the reason why we are
    > thinking of finding a way to reduce the buffer sizes
    > of TCP protocol.
    >
    > So, *Is there a way to reduce the TCP buffer size????



    In the future, please don't top post.

    Unfortunately, there's no real way to reduce the buffering done by TCP
    unless you have very low level control over both stacks, and more
    control than is usually exposed to applications. You can influence it
    various ways, for example with ioctl-like calls. In Windows take a
    look at the setsockoptions SO_SNDBUF and SO_RCVBUF, for example.
    Unfortunately those rarely let you get the buffering down to the few
    bytes you're presumably looking for.

    Anyway, is the serial port virtualization canned, or something you
    did, or something you could do? If it's your own protocol, build in
    explicit byte acknowledgements every time the virtual serial port
    actually accepts a byte.

    As I mentioned, messed up flow control is a pretty common problem with
    this class of devices. It's not a problem if the device in question
    is a modem, with pleanty of buffering of its own, or something similar
    to that with lots of streaming capability. Unfortunately outside of
    that there are common problems. You might also look at serial port
    options for the virtual serial port (some of the DCB settings, as well
    as and configuration options for the device itself).

  6. Re: Reduce or disable the TCP buffers

    In article
    <8d8b0350-a12b-4925-9217-fc7e01d80907@k39g2000hsf.googlegroups.com>,
    "robertwessel2@yahoo.com" wrote:

    > On Jan 10, 8:54*pm, Barry Margolin wrote:
    > > In article
    > > <08bc2741-21f3-4c9d-b71c-7c03b015e...@s12g2000prg.googlegroups.com>,
    > >
    > >
    > >
    > >
    > >
    > > *karthikphanin...@gmail.com wrote:
    > > > Hi all

    > >
    > > > I have a problem with TCP buffers.

    > >
    > > > First let me explain you about my application.

    > >
    > > > We have a electronic board which serves Serial ports on LAN.

    > >
    > > > i.e. The LAN users can access the serial ports on this board as if
    > > > they are in their PC. The board is accessible through ethernet to all
    > > > the PC's.

    > >
    > > > Now that when two PC's are communicating using the serial ports on
    > > > this board using XON/XOFF flow control and when the receiver end is
    > > > pausing the reception the sender is still transmitting, whereas the
    > > > transmitter also should stop sending the data.

    > >
    > > > Actually we could figure out the problem, i.e. the buffering is taking
    > > > place in the TCP protocol, so the flow control is not getting
    > > > triggered.
    > > > Is there any way to reduce the TCP buffers, We have already tried the
    > > > setsockopt function to reduce the RECV and SEND buffers, but still the
    > > > buffering is taking place and the problem persists.

    > >
    > > > Is there any other alternate way to disable the TCP buffers other than
    > > > setsockopt.

    > >
    > > Why do you need to do this? *What's wrong with the transmitter
    > > continuing to send, as long as the board has buffer space for it?
    > >
    > > When the buffer fills up the receiver will close the TCP window, and
    > > then the transmitter will stop.

    >
    >
    > His problem is that the serial port flow control (the XON/XOFF) is
    > happening at the PC, and by the time the PC processes the XOFF from
    > the device, a bunch of stuff is already queued up in TCP buffers and
    > elsewhere.
    >
    > This is actually a pretty common problem. USB serial port dongles
    > suffer from it as well, and devices that have relatively tight timing
    > requirements tend to break badly.


    I see -- it's basically the same problem he would have if he had a
    really high latency serial connection, e.g. a cross-country leased line.

    As you said, the best solution is to have the flow control implemented
    at the other end of the connection, so that the latency in transmitting
    the XON would not be an issue. Even better would be to use hardware
    flow control -- inline flow control has ALWAYS been problematic.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  7. Re: Reduce or disable the TCP buffers

    On Jan 12, 4:13*am, "robertwess...@yahoo.com"
    wrote:
    > On Jan 11, 7:30*am, karthikphanin...@gmail.com wrote:
    >
    >
    >
    >
    >
    > > Hi,

    >
    > > Thanks immensely for your resoponces.

    >
    > > Yes. There is nothing wrong in buffering the data by TCP buffers,
    > > but I want to simulate the exact serial communication where
    > > the transmission will be stopped if the receiver pauses reception.

    >
    > > We did not implement any flow-control at application level.
    > > We are using the Teratermpro application.

    >
    > > We have implemented flow-control at the box where the serial ports
    > > exists.

    >
    > > PC1 is sending data through serial port (Port-1) of the box sitting on
    > > the network,
    > > which is connected to Port2 of the same box using null modem cable.
    > > PC2 is receiving data through Port-2. {Port-1 is virtualized in PC1
    > > and Port-2 is virtualized in PC-2}.

    >
    > > It is observed that the Port 2's receive buffers never reaches it's
    > > trigger level because the data is getting
    > > buffered at the TCP socket of PC2. This is the reason why we are
    > > thinking of finding a way to reduce the buffer sizes
    > > of TCP protocol.

    >
    > > So, *Is there a way to reduce the TCP buffer size????

    >
    > In the future, please don't top post.
    >
    > Unfortunately, there's no real way to reduce the buffering done by TCP
    > unless you have very low level control over both stacks, and more
    > control than is usually exposed to applications. *You can influence it
    > various ways, for example with ioctl-like calls. *In Windows take a
    > look at the setsockoptions SO_SNDBUF and SO_RCVBUF, for example.
    > Unfortunately those rarely let you get the buffering down to the few
    > bytes you're presumably looking for.
    >
    > Anyway, is the serial port virtualization canned, or something you
    > did, or something you could do? *If it's your own protocol, build in
    > explicit byte acknowledgements every time the virtual serial port
    > actually accepts a byte.
    >
    > As I mentioned, messed up flow control is a pretty common problem with
    > this class of devices. *It's not a problem if the device in question
    > is a modem, with pleanty of buffering of its own, or something similar
    > to that with lots of streaming capability. *Unfortunately outside of
    > that there are common problems. *You might also look at serial port
    > options for the virtual serial port (some of the DCB settings, as well
    > as and configuration options for the device itself).- Hide quoted text -
    >
    > - Show quoted text -


    Hi,

    Thanks for responding once again.

    I am just curious to know the following things.

    How much data the TCP protocol driver can buffer? [Both at send side
    and receive side.]

    Up to how much we can reduce the send and receive buffering by using
    SO_SNDBUF, SO_RCVBUF?

    I just want to know the numbers.

  8. Re: Reduce or disable the TCP buffers

    karthikphaninder@gmail.com wrote:
    > I am just curious to know the following things.


    > How much data the TCP protocol driver can buffer? [Both at send side
    > and receive side.]


    In broad handwaving terms, SO_SNDBUF and SO_RCVBUF worth of data, but
    some stacks take a couple liberties with the values you pass to
    setsockopt() (Linux will increase it for example, by multiplying by
    2X, using some of the space for overhead etc etc...)

    > Up to how much we can reduce the send and receive buffering by using
    > SO_SNDBUF, SO_RCVBUF?


    > I just want to know the numbers.


    It depends entirely on the TCP stack on the system(s).

    The only way to know for certain is to actually try it out with some
    test program(s). You could use netperf to see about the settings of
    SO_SNDBUF and SO_RCVBUF, but it won't tell you how much data can be
    buffered overall since it never stops to wait

    rick jones
    --
    The glass is neither half-empty nor half-full. The glass has a leak.
    The real question is "Can it be patched?"
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  9. Re: Reduce or disable the TCP buffers

    On Jan 16, 8:49*am, karthikphanin...@gmail.com wrote:
    > On Jan 12, 4:13*am, "robertwess...@yahoo.com"
    >
    >
    >
    >
    >
    > wrote:
    > > On Jan 11, 7:30*am, karthikphanin...@gmail.com wrote:

    >
    > > > Hi,

    >
    > > > Thanks immensely for your resoponces.

    >
    > > > Yes. There is nothing wrong in buffering the data by TCP buffers,
    > > > but I want to simulate the exact serial communication where
    > > > the transmission will be stopped if the receiver pauses reception.

    >
    > > > We did not implement any flow-control at application level.
    > > > We are using the Teratermpro application.

    >
    > > > We have implemented flow-control at the box where the serial ports
    > > > exists.

    >
    > > > PC1 is sending data through serial port (Port-1) of the box sitting on
    > > > the network,
    > > > which is connected to Port2 of the same box using null modem cable.
    > > > PC2 is receiving data through Port-2. {Port-1 is virtualized in PC1
    > > > and Port-2 is virtualized in PC-2}.

    >
    > > > It is observed that the Port 2's receive buffers never reaches it's
    > > > trigger level because the data is getting
    > > > buffered at the TCP socket of PC2. This is the reason why we are
    > > > thinking of finding a way to reduce the buffer sizes
    > > > of TCP protocol.

    >
    > > > So, *Is there a way to reduce the TCP buffer size????

    >
    > > In the future, please don't top post.

    >
    > > Unfortunately, there's no real way to reduce the buffering done by TCP
    > > unless you have very low level control over both stacks, and more
    > > control than is usually exposed to applications. *You can influence it
    > > various ways, for example with ioctl-like calls. *In Windows take a
    > > look at the setsockoptions SO_SNDBUF and SO_RCVBUF, for example.
    > > Unfortunately those rarely let you get the buffering down to the few
    > > bytes you're presumably looking for.

    >
    > > Anyway, is the serial port virtualization canned, or something you
    > > did, or something you could do? *If it's your own protocol, build in
    > > explicit byte acknowledgements every time the virtual serial port
    > > actually accepts a byte.

    >
    > > As I mentioned, messed up flow control is a pretty common problem with
    > > this class of devices. *It's not a problem if the device in question
    > > is a modem, with pleanty of buffering of its own, or something similar
    > > to that with lots of streaming capability. *Unfortunately outside of
    > > that there are common problems. *You might also look at serial port
    > > options for the virtual serial port (some of the DCB settings, as well
    > > as and configuration options for the device itself).- Hide quoted text -

    >
    > > - Show quoted text -

    >
    > Hi,
    >
    > Thanks for responding once again.
    >
    > I am just curious to know the following things.
    >
    > How much data the TCP protocol driver can buffer? [Both at send side
    > and receive side.]
    >
    > Up to how much we can reduce the send and receive buffering by using
    > SO_SNDBUF, SO_RCVBUF?
    >
    > I just want to know the numbers.



    It's hard to specify an upper limit. Buffering at either end is
    outside the scope of the TCP/IP RFCs, so there's no standard way, or
    even a required way, to set/limit that. As far as the RFCs are
    concerned, there needs to be at least enough buffering to accommodate
    the negotiated window size, but additional buffering outside of that
    is perfectly acceptable. The window size is sometimes influenced by
    settings like SO_SND/RCVBUF, sometime by other settings, although
    that's not guaranteed, and sometimes SO_SND/RCVBUF only impact
    additional buffering.

    In any event, most systems will likely set a lower limit to what
    they'll let you set SO_SNDBUF to.


  10. Re: Reduce or disable the TCP buffers

    "robertwessel2@yahoo.com" writes:

    > It's hard to specify an upper limit.




    Well, it's 2*16 (64k) without window scaling. With window scaling,
    it's 2**14 times larger or 1073741824

    --
    Posted via a free Usenet account from http://www.teranews.com


  11. Re: Reduce or disable the TCP buffers

    On Jan 17, 9:16*pm, Bruce Barnett
    wrote:
    > "robertwess...@yahoo.com" writes:
    > > It's hard to specify an upper limit. *

    >
    > Well, it's 2*16 (64k) without window scaling. *With window scaling,
    > it's 2**14 times larger or 1073741824



    The negotiated window implies the *minimum* amount. There is nothing
    at all preventing additional buffering at either end. In fact it's
    quite common.

+ Reply to Thread