Re: Calling for socket type opinions... -- RPG400-L

> The question is:  Would it be better to use the TCP protocol and have a
> socket listen() and create more descriptors, or would UDP be more
> appropriate?  My TCP hang up is that the connections may be broken by
> walking into an area of no RF coverage or the handheld going into
> standby mode.  My UDP hang up is, well, it's UDP.

Both TCP and UDP are very good for their intended purpose.   The real
question is:  How do you intend your program to work?

Here are the problems with UDP:
 1) UDP does not detect when the datagram got lost (i.e. did not arrive
      at it's destination)
 2) UDP does not guarentee that the datagrams will be received in the
      same order that you wrote them.
 3) UDP datagrams can only hold a relatively small amount of data
      (the size depends on how your TCP/IP is set up) per datagram.

I wrote a very similar program to yours about 3 years ago.  It prints
barcoded labels for each case of sausage that we make, and sends the
details for each label (item no, batch no, serial number, weight,
date/time, etc) back to our AS/400.

I decided to use UDP for this application, because these printers had to
be able to run even if the AS/400 wasn't available.  I didn't want to keep
a TCP session open all the time in case there was a network glitch, or the
AS/400 went down, but I also didn't want to deal with the overhead of
opening up a new TCP session to send each record (approx 100 bytes each)

So, I used UDP.   Here's what I had to do:

   1)  I created a background process on the PC that drives the printers
       which is always running and receives all of the data from up to
       32 printers connected to that PC.

   2)  Each time a label is printed, this background process would both
       send the UDP datagram to the AS/400 and save the box data to a
       local file with a timestamp.

   3)  When a record was received by the AS/400, it would send back a
       UDP datagram to acknowledge that box.  (Each box has a unique
       serial number, so I can tell which box is being acknowledged)

   4)  Whem my background process receives an ack, it removes that
       record from the local file.

   5)  Periodically, the background process checks it's queue (in the
       local file) for boxes that have never been acknowledged, and
       re-sends them if they were originally sent more than 2 minutes
       ago.  So, if the AS/400 goes down, the records will be re-sent
       at 2 minute intervals until they get received.

So, this system is rather complex... it took quite a bit of code to do
this, but it works very well.

If I had just done a simple "connect and send" application, and I just
wanted the process to fail and warn the user when the network wasn't
available, using TCP would've saved me a lot of work.

Perhaps that'll provide you with food for thought...