× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: A problem with TCP/IP...
  • From: "Bob Crothers" <bob@xxxxxxxxxxxxxx>
  • Date: Thu, 16 Mar 2000 08:24:32 -0500
  • Importance: Normal

Dan,

This is not a problem with TCP/IP....it is how it works.  TCP says that if
you send 2k bytes, you will receive 2k bytes.  It does NOT say you will
receive a single 2k buffer, but the buffers you receive will add up to 2k
and the bytes will be in the same order as sent.

You need to either have some sort of header or something that will tell you
how many bytes you are sending, or use some sort of "terminator" character.

Myself, I use the first approach.  All of my TCP/IP goes thru a common
module (AS/400 or WinXX).  This module adds a small header that has a) the
number of uncompressed bytes, b) number of compressed bytes, c) header
version number (VERY important!), and some flags for Compression
status/type, Encryption status/type, and some other important info to my
applications.

These modules then "reassemble" the buffers on the receive side.  And
decompress/decrypt also.  I have been using this approach for many years
(6+) and it has worked very well.  And works with binary data also.

If you data is text, then you can tag a delimiter character.  Many of the
standard Internet applications (SMTP, HTTP, etc) use the new line character.
If you are AS/400 to AS/400, a hex FF would be more "natural".  Then on the
receiving side, the program receives a buffer, and then starts giving it to
the application till it hits the delimiter.  Then signals "End of Record".

Also, note that not only can a single send be broken up, but multiple sends
can also be combined.   You need to account for all variations on the theme!
And if you are going over multiple network segments and/or the Internet,
this will be greatly magnified.  I have seen many folks not have a problem
while they are going between machines with small sends on the same network.
Everything works great.  Then, when they expand their scope and start
hitting the 'net, all heck breaks loose.  Been there, done that, bought the
t-shirt! <g>

After you get over this hurdle, Sockets programs are actually very easy to
do.

Regards,
Bob Crothers
Cornerstone Communications
www.theunifier.com and www.faxserver401.com
If you are a dog lover: www.cstoneindy.com/bob
Voice: 317-802-0107 Ext 103
Fax:    317-803-3450


-----Original Message-----
From: owner-midrange-l@midrange.com [mailto:owner-midrange-l@midrange.com]On
Behalf Of Dan Rasch
Sent: Thursday, March 16, 2000 12:02 AM
To: MIDRANGE-L@midrange.com
Subject: A problem with TCP/IP...
On the Server (AS400 production machine), we have an ILE RPG program,
using C prototypes, acting as the server module. On the Client (AS400
development machine), we have an ILE RPG program, using C prototypes,
acting as the client module.  They both are using TCP/IP Sockets for the
communications between the machines.



We are sending and receiving a buffer of data that is 2048 in length.  The
problem that we are having seems to be on the Server (AS400 production
machine).  When we receive the buffer on the Server, it does / does not
get the entire buffer in one receive process.  We have added code to
perform an additional receive when it does not get the entire buffer in
the first receive.


The following is what is printed from the server module during the
execution of this process on the AS400 production machine.  The client
module is on the AS400 development machine.


Opened Tcp/Ip Port#: 0000010001

Listening  on Port#: 0000010001

Reading, client

Received Request: 1      ACTION =    LEN = 0000002048 Rtncd = 0000001404
first receive

Received Request:        ACTION =    LEN = 0000002048 Rtncd = 0000000644
second receive

Sent back: One   Rtncd = 0000002048

Reading, client

Received Request: 2      ACTION =    LEN = 0000002048 Rtncd = 0000001404
first receive

Received Request:        ACTION =    LEN = 0000002048 Rtncd = 0000000644
second receive

Sent back: Two   Rtncd = 0000002048

Reading, client

Received Request: 3      ACTION =    LEN = 0000002048 Rtncd = 0000001404
first receive

Received Request:        ACTION =    LEN = 0000002048 Rtncd = 0000000644
second receive

Sent back: Three Rtncd = 0000002048

Reading, client

Received Request: 1      ACTION =    LEN = 0000002048 Rtncd = 0000001404
first receive

Received Request:        ACTION =    LEN = 0000002048 Rtncd = 0000000644
second receive

Sent back: One   Rtncd = 0000002048

Reading, client

Received Request: 2      ACTION =    LEN = 0000002048 Rtncd = 0000002048
received ok

Sent back: Two   Rtncd = 0000002048

Reading, client

Received Request: e      ACTION =    LEN = 0000002048 Rtncd = 0000001404
first receive

Received Request:        ACTION =    LEN = 0000002048 Rtncd = 0000000644
second receive

Sent back: Bad...Rtncd = 0000002048

Reading, client

Received Request: eoj    ACTION =    LEN = 0000002048 Rtncd = 0000001404
first receive

Received Request:        ACTION =    LEN = 0000002048 Rtncd = 0000000644
second receive

Sent back: ok    Rtncd = 0000002048

Closing Client

Closing Server


As you can see it does / does not receive the entire buffer on one receive
process.

 Example # 2.


In this example we are running the Server module on the AS400 development
machine and the Client module on the AS400 production machine.


We are sending and receiving the same buffer of data that is 2048 in
lenth.  As you can see, the server module receives each send as one 2048
buffer.


The following is what is printed from the server module during the
execution of this process on the AS400 development machine.  The client
module is on the AS400 production machine.


Opened Tcp/Ip Port#: 0000011001

Listening  on Port#: 0000011001

Reading, client

Received Request: 1      ACTION =    LEN = 0000002048 Rtncd = 0000002048
received ok

Sent back: One   Rtncd = 0000002048

Reading, client

Received Request: 2      ACTION =    LEN = 0000002048 Rtncd = 0000002048
received ok

Sent back: Two   Rtncd = 0000002048

Reading, client

Received Request: 3      ACTION =    LEN = 0000002048 Rtncd = 0000002048
received ok

Sent back: Three Rtncd = 0000002048

Reading, client

Received Request: 1      ACTION =    LEN = 0000002048 Rtncd = 0000002048
received ok

Sent back: One   Rtncd = 0000002048

Reading, client

Received Request: 2      ACTION =    LEN = 0000002048 Rtncd = 0000002048
received ok

Sent back: Two   Rtncd = 0000002048

Reading, client

Received Request: 3      ACTION =    LEN = 0000002048 Rtncd = 0000002048
received ok

Sent back: Three Rtncd = 0000002048

Reading, client

Received Request: eoj    ACTION =    LEN = 0000002048 Rtncd = 0000002048
received ok

Sent back: ok    Rtncd = 0000002048

Closing Client

Closing Server


As you can see it does / does not receive the entire buffer on one receive
process.


We have executed both the server and client modules on each of the
machines and they perform correctly every time.  We have reviewed both the
ILE RPG and C modules to insure that all buffers are set to 2048.


The problem is that we should not have to do multiple receives to get the
entire buffer of information that is being sent.  At this point we are in
need of assistance in the resolution of this problem.




Sorry for the tag line appearing out of order.....

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.