Subject: tn3270e header

From: Bimal Shah <[email-masked]>
Date: Tue, 14 Jul 1998 15:49:57 -0400

Should  client/server handle  <TN3270E Header> and   <data> received
in two separate network packets? I know, if "data" portion is received in two
separate network packets then recipient should handle it. But in this case
recipient first receives only "header" and then "data".

For example,  all the time I have seen BIND_IMAGE coming in to client as
one network packet......

 Outbound data    :..............*gy*........&.&...*NRAVM17...
                   000003000b938008a0008000015150000ddcedff0fe
                   30000113310000778702000008080300759154170ff

But  what if it's coming in to client as.....

 Outbound data    :.....
                   00000
                   30000

 Outbound data    :.........*gy*........&.&...*NRAVM17.
                   3000b938008a0008000015150000ddcedff0
                   113310000778702000008080300759154170

 Outbound data    :..
                   fe
                   ff

Should client process this BIND without any error?
Seems like RFC 2355 (TN3270 Enhancements) is not addressing
this issue.

-  Bimal Shah (Pcom - IBM)

"On whatever trails you walk, there are no strangers only friends not yet met"

---

From: Michael Boe <[email-masked]>
Date: Tue, 14 Jul 1998 13:28:39 -0700 (PDT)

On 14-Jul-98 at 16:05, Bimal Shah ([email-masked]) wrote:
> in two separate network packets? I know, if "data" portion is received in
> two separate network packets then recipient should handle it. But in this
> case recipient first receives only "header" and then "data".
>

IMHO, the server depicted in the above sequence isn't doing anyone (even
itself) any favors by polluting the network with three packets when one would
do. But....it's legal and the client should be able to handle it.  Why? Because
in general, it's impossible to guarantee where data "splits" in TCP; that's the
essence of a "byte stream" transport protocol (as opposed to a message-oriented
one). The client must be prepared to allow splits pretty much anywhere: after
the TN3270E header, or even between the FF and the EF.

For instance, suppose that the server was about to send out the BIND all in one
packet.  However, the server had just sent a USS10 message to the client which
was (in total) 1019 bytes long.  And the payload MTU for the connection is 512
bytes.  That means that the first packet sent by the server would contain the
first 512 bytes of the USS10 message. The other 507 bytes might be sitting
waiting on the send-window to open up.

So when the server TN3270 app calls the TCP stacks with a request to send the
TN3270E BIND packet, the TCP stack is quite justified in appending the first
five bytes of the BIND packet after the last of the 507 remaining bytes of the
USS10 message.

>From the client's perspective, it receives the following:

   512 bytes:    TN3270E(SSCP-LU)[data....]
   512 bytes:    [....data]<IAC><EOR>TN3270E(BIND)
    34 bytes:    [bind-image data]<IAC><EOR>

Now the client still has the same problem.

> Seems like RFC 2355 (TN3270 Enhancements) is not addressing

This problem is endemic to any application that sits on top of TCPIP; all
applications running over TCP must allow for "data dribbling."

/msb

---

From: Fred Bohle <[email-masked]>
Date: Tue, 14 Jul 1998 17:08:38 -0400

> ....it's legal and the client should be able to handle it.  Why? Because

I agree wholeheartedly.  This is a fundamental example of why layering is
important.It should not matter if each byte arrived in its own packet!  The client
should not be
concerned with how the data is delivered.  It should process it as it arrives.

I have seen some terrible violations of layering before.  An AS/400 implementation
would
not send a TCP ACK packet unless the proper Telnet data was contained in the
packet!
With the Nagle algorithm in force, the remaining Telnet data would not be sent
until
the previous data was ACKed.  This led to retransmissions, and eventual timeout,
breaking the sessions.  And the AS/400 developer had the nerve to tell me that we
were
wrong!

Fred

--
------------------------------------------------------------------------
Fred Bohle                      EMAIL: [email-masked]
Interlink Computer Sciences     AT&T : 410-992-7750 x314
9250 Rumsey Road, Suite 200
Columbia, MD 21045-1946
------------------------------------------------------------------------

---

From: Paul Chmielewski <[email-masked]>
Date: Wed, 15 Jul 1998 11:02:33 -0500 (CDT)

Excerpts from mail: 14-Jul-98 Re: tn3270e header Fred
[email-masked] (1768*)

An AS/400 implementation would not send a TCP ACK packet unless the
proper Telnet data was contained in the packet!  With the Nagle
algorithm in force, the remaining Telnet data would not be sent until
the previous data was ACKed.  This led to retransmissions, and eventual
timeout, breaking the sessions.  And the AS/400 developer had the nerve
to tell me that we were wrong!

As an AS/400 TCP/IP developer, I can tell you that you were given bad
information if somebody told you that the content of the Telnet data
controlled whether or not TCP would send an ACK.  Sorry if that was the
case.  It is possible that the content could indirectly affect *when*
TCP would send the ACK just due to the delayed ACK algorithm in TCP
which attempts to piggy-back the ACK on data going in the opposite
direction.  If the data that the client sent did not trigger the server
to send something in return, then you could see the ACK dally come into
play.  If I remember, the ACK dally is roughly 100-200ms.

-Paul Chmielewski ([email-masked])
-AS/400 Communications Development
-IBM Rochester, MN