× 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: Socket programming in MI
  • From: Jim Langston <jimlangston@xxxxxxxxxxxxxxxx>
  • Date: Tue, 01 May 2001 08:40:01 -0700
  • Organization: Pacer International

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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.