× 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 related question...
  • From: Scott Klement <klemscot@xxxxxxxxxxxx>
  • Date: Fri, 24 Mar 2000 17:49:35 -0600 (CST)

On Fri, 24 Mar 2000, Sanjiv Hati wrote:
> Hi
> 
> I have a client program on AS/400 (written in ILE C)
> which send one transaction to Win NT server. The
> server program (Win NT) sends the reply string which
> is in a mixed format (ASCII and binary). I checked on
> Win NT that the length of reply string is around 2K
> bytes.
> When I do a socket read() from client program (AS400),
> I receive 536 bytes instead of 2K bytes. I have
> defined buffer length parameter of read() to a maximum
> of 32766 bytes.
> I am working on OS/400 V4R3 with TCP/IP support
> exclusively.
> Can anyone suggest me with a solution?? I highly
> appreciate  your reply.
> 
> Thanks in advance.
> Sanjiv

First of all, this is the RPG mailing list, not the ILE C list.  I'm,
therefore, going to pretend that your question was regarding an RPG
program, instead of C.  (Since they call the same read() function, it
shouldnt actually matter)

Next question is, what protocol are you sending the data under?   I assume
that you're either using TCP (SOCK_STREAM) or UDP (SOCK_DGRAM).  But your
message didn't state WHICH.

These are my "best guesses" for why you'd have this problem:

If you're using UDP, you're limited by the amount of data that will fit in
a single datagram.  The reason I'm suspecting this possibility is that 
"536" plus the 40-byte IP header comes to 576, which is a very common
value for the maximum transmission unit in IP.  Solution?  Use TCP, or
send multiple datagrams.

If you're using TCP, you need to keep in mind that the read() function 
call will only return the amount of data thats "currently available" on
the socket.   Remember, it doesn't know how long the data thats being sent
is!  When you do a read() you're getting whatever's currently in the
receive buffer.  You need a way to determine where the end of the data 
is, and keep reading until you've received it all. 

If the amount of data that you're sending has a "Fixed length" you might
try a loop that does a read() until it has the amount of data that you
require.   For example, if you need 2048 bytes, you have a loop that first
does a read() for 2048 bytes, then adds whatever it receives to a buffer,
and subtracts the number of bytes received from the amount still required.
Then read for THAT amount, etc...  until you have the full 2k.

If the amount of data that you're sending is variable in length, you'll
need to devise some method of "knowing" when the data is over.  For
example, you might keep reading your data, in a loop, until you get an
error saying that the sending application disconnected their side of 
the connection...    Another idea would be to have the sending application 
specify how many bytes its going to send before sending the actual data,
so you can use the same approach that you would for a "fixed length".

Hope that helps...


+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-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.