TCP interactive data flow - TCP-IP

This is a discussion on TCP interactive data flow - TCP-IP ; On Jul 17, 1:14*am, "Mark (newsgroups)" wrote: > > 4) Hope the 3rt party comes out what a *proper* solution on their > > side, sending all the data in a single write call like they're > > supposed to. ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 43 of 43

Thread: TCP interactive data flow

  1. Re: TCP interactive data flow

    On Jul 17, 1:14*am, "Mark (newsgroups)"
    wrote:

    > > 4) Hope the 3rt party comes out what a *proper* solution on their
    > > side, sending all the data in a single write call like they're
    > > supposed to.

    >
    > Thanks but you lack understanding of the problem space. I'm reluctant
    > to actually say what it is we're doing due to sensitivities, but
    > needless to say you should accept that the situation I described is as
    > it is for a reason (I don't mean the nagling I mean sending the
    > "acknowledge" and "dataX" in seperate write calls).


    If the two sends are for a reason, then the 200mS delay is for a
    reason. One is a direct consequence of the other.

    > > 5) Disabling Nagle on your side and dribbling data in the delay
    > > interval to give your ACKs something to piggyback on.

    >
    > Firstly, I don't think this would solve the problem since data can be
    > sporadic therefore we'd still see the delay in many cases. Which is
    > not a solution. Secondly, as I mentioned, I do not have control over
    > the underlying tcp/ip communication which is done via an api provided.


    Then wrap both ends of the connection with your own proxy. If you
    can't even do that, then I'd say your problem is so specialized and
    secret that nobody can give you advice with just what you've
    disclosed.

    DS

  2. Re: TCP interactive data flow

    > > Thanks but you lack understanding of the problem space. I'm
    > > reluctant to actually say what it is we're doing due to
    > > sensitivities, but needless to say you should accept that the
    > > situation I described is as it is for a reason (I don't mean the
    > > nagling I mean sending the "acknowledge" and "dataX" in seperate
    > > write calls).


    Well, it is difficult to help optimize with our hands tied behind our
    backs that way

    > If the two sends are for a reason, then the 200mS delay is for a
    > reason. One is a direct consequence of the other.


    I would rather see the application-layer ack and the response in the
    same send, but _if_ they are not logically associated sends, then in
    broad terms it is "ok" (not great) to disable Nagle then. Rather but
    not entirely like how it might be considered OK for X11 to do that to
    keep mouse movements flowing.

    rick jones
    --
    denial, anger, bargaining, depression, acceptance, rebirth...
    where do you want to be today?
    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...

  3. Re: TCP interactive data flow

    On 2008-07-16 21:50:10 -0400, David Schwartz said:

    > 4) Hope the 3rt party comes out what a *proper* solution on their
    > side, sending all the data in a single write call like they're
    > supposed to.



    Indeed, there are too many applications out there nowadays, and the
    associating attitude by their developers that TCP sockets are one "big
    happy pipe" you can keep dumping stuff into.

    This may seem like whacking a fly with a baseball bat, but if you have
    a really picayune problem, where you can't or don't want to change
    stack behavior because your application is co-located with others and
    those other applications might not play nice with your tweaks, consider
    one of the following:

    - Move the application to its own box - if it's a special case, then
    isolate it out so any tweaking for that third-party application can be
    done in peace. If I were in the OP's shoes @ his company and management
    said no, I'd tell them to be happy with being short-sighted, and enjoy
    the consequences, etc.

    - Create a "split" on the existing box where you engage the use of a
    ToE (TCP Offload Engine) card, and have the application bind to / use
    that interface / address combination on the existing hardware, after a
    thorough understanding of the ToE cards tweak-ables for network stack
    settings, etc. In this case you're "installing two TCP/IP stacks" on
    the box - the one the OS uses, and the one the ToE NIC uses, etc. The
    application is the root cause, indeed, but the extra hardware could
    provide you the tweak you might want or need. I'm not interested in
    hearing any flames from this suggestion about how ToE cards are evil or
    how we should just write TCP/IP stacks correctly, etc. ToE cards, like
    any hardware are good for some problems and not good for others. I've
    personally solved some bad application issues with them.

    - Probably the best solution here isn't even the technological one -
    issues like this fester and become worse - it's likely more important
    to consider the functions of what you're trying to do, and if the
    current 3rd party application isn't getting it done, replace it. If the
    3rd party application is linked to specific hardware and isn't getting
    the job done, evaluate a competitor. If there is no competitor, I'm
    sure there are many companies hungry for new business that would like
    to become one.

    /dmfh

    --
    _ __ _
    __| |_ __ / _| |_ 01100100 01101101
    / _` | ' \| _| ' \ 01100110 01101000
    \__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx


+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3