RE: Socket program problem

[Scott Klement <klemscot@xxxxxxxxxxxx>]

I don't like the idea of using x'FF' for an ACK.  I think that's an ugly
solution, since you can't do testing with a telnet client, and it's not
apparent to the human eye what's going on.

It's also an inflexible solution, because you can't have different error
messages.  That means that if something goes wrong, it'll be really hard
to troubleshoot, since you won't have any way to know WHAT went wrong, all
you know is that SOMETHING went wrong.

A better (and more widely used) method is to give messages from the server
that take the form:
   NNN MessageMessageMessage

Where NNN is a 3-digit computer-readable message ID, and the
MessageMessageMEssage is a human-readable message text.   For example:

200 Command Accepted
or
506 Error opening file FOO

Keeping that in mind, here's how I would design this "protocol":

1) iSeries server waits for a connection.
2) When connection is received, iSeries sends: 200 Hello<cr><lf>
3) PC receives response, it knows that "200" means "success" and
      it sends its request:  GET fileidentifier<cr><lf>

      I like the idea of having a command like "GET" because it
      makes it much easier to expand the protocol later, without
      breaking backwards compatibility, and checking for the "GET"
      characters is not difficult to code.

      For example, maybe right now you want to do a GET with an
      ACK only at the end of the file.  But later, you might
      want to add capability for an ack of each "record" received.
      You could add a new command GETACK to do that without breaking
      backward compatibility for existing clients.

3) Server does any processing it needs to do before sending the file,
     if all goes well, it sends back:
         201 LLLLLL File follows<cr><lf>
        The "LLLLL" should be the length of the file in bytes, so the
        PC knows how much to receive.
     if something goes wrong it sends
         501 File not available<cr><lf>
         502 You do not have access<cr><lf>
         503 Other Error here<cr><lf>
         etc,etc

4) PC reads this response.
       -- If it's an error, it pops up a MessageBox showing the error to
          the user, and then aborts the process.  Then, the user can
          call for support, if he doesn't understand the problem.
       -- If it's not an error, the iSeries will immediately send the
          file, and the PC will receive the number of bytes indicated.

5) After the file length has been received, the AS/400 sends another
     message like:
        202 file complete<cr><lf>
     This would be another place where the iSeries could report an
     error if anything went wrong.

6) Now, the PC can either send another GET command, if it wants another
     file, or it can send QUIT<cr><lf> to tell the iSeries it's done.
     This way, the iSeries never closes the connection until the PC
     has sent something back.

That's the way that I would go about it, anyway.   It also is very similar
to the way that other Internet protocols work, which means that it'll be
easier for the people that follow you to understand (Assuming they have
TCP/IP experience) and it'll work better with things like packet sniffers,
proxies, etc.

Just a suggestion...


On Thu, 11 Sep 2003, John Allen wrote:
>
> New program would
> 1) iSeries waiting for request
> 2) PC send req to iSeries for file X, then waits for ack from iSeries
> 3) iSeries receives request for file x, sends ack to the PC that the request
> was received and spawns Job A to build the file and transmit to PC
> 4) PC get ack from iseries and waits for data
> 5) iSeries Job A build file and sends record 1 (with X'FF' at end of record)
> then waits for ack from PC that the record was received
> PC receives record 1 and knows it is complete because of x'FF' and send ack
> to the iSeries
> 6) iSeries receives ack from PC and the two go back and forth til all
> records are sent and received.
>
> Is there any chance this might fix my problem?