RE: Socket programming in MI

Jim is right.  TCP packets are guaranteed to arrive at the destination
and in the same order sent, but NOT the same packet sizes.

So, you could send a 4k packet.

It might arrive as 1 1k, then 2 512, and 1 2k.  Or any combination
there of.

Bottom line is to make no assumptions.

I handle this by wrapping the socket calls with a class (C++) of my own
that re-assembles the packets to look like they where when sent by the
other side.  This way the application doesn't know or care what the
network does to your data.

Regards,
Bob Crothers
Cornerstone Communications
http://www.cstoneindy.com




-----Original Message-----
From: owner-mi400@midrange.com [mailto:owner-mi400@midrange.com]On
Behalf Of Jim Langston
Sent: Tuesday, May 01, 2001 10:40 AM
To: MI400@midrange.com
Subject: Re: Socket programming in MI

Well, Harry, there you have one of the things about TCP/IP...

Packets are not guaranteed to remain the same size on their trip.
If a machine sends a 1k packet, it can, and a lot of time does, get
broken
down into 2 576byte packets at the receiving end.  You should never,
however, wind up with 2 1K packets becoming 1 2K packet.

What will happen is somewhere along the line some router/switch will
have
it's packet size set less than the transmitting computer.  It will
receive
a 1K packet, and break it into 2 576 byte packets (I think breaking 4K
packets into 4 1K packets is most common).

The receiving computer receives what the network sends them.  The
receiving
computer has no way of knowing if it should be sticking packets
together or
not, so it doesn't.  That's up to your software.

There are things you can do to help, though.  Make sure your server has
a
large enough packet size so it doesn't break packets up itself.  You
should
find out what the packet size your ISP is sending, and set your server
to
that size (if this is a local network, just make sure all your machines
have
the same packet size).

On the AS/400 CFGTCP I see that the AS/400 calls it a "Maximum
Transmission Unit"
or MTU.  You might be tempted to just set this up to the maximum 16388
to receive
a big as packets as you can, but you can negatively effect network
performance that
way.  How?  You send a 16388 packet through your network, and some
intermittent machine,
or even the host machine, is going to have to break the packet down
into it's own
MTU size before sending it on, or receiving it.  And this takes time
(not much per
packet, of course, but it definitely effects network performance).

I believe the default is *LIND which pulls the MTU from the line
description.  I see
on my system the default "Maximum Frame" which is the same thing, is
1496 which seems
to be the default.  I believe the optimal size depends on your network.

Regards,

Jim Langston

Me transmitte sursum, Caledoni!

Harry Williams wrote:
>
> Is there a way to read the TCP/IP server buffer to find the size of
the
> buffer the client sent.  The sockets seem to know the length of what
is
> sent, but since I cannot find it in sockets, i thought I could get it
> from MI.
>
> The example is where the client sends 1000 bytes, and the server
reads
> 100. When this happens the server reads 10 times.  I was looking for
> some way to read the incomming buffer size and read it once.
>
> Harry
+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
dr2@cssas400.com
+---


+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---