× 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.



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

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.