Re: Help with Socket calls in Datablade IDS/UDO 9.14X
Posted in 1998
drchen@my-dejanews.com wrote: > > Hi, we are migrating one function from Illustra to IDS/UDO 9.14x. This > function needs to make TCP/IP socket call. It worked fine in Illustra but > failed in Informix, complaining memory type of problem. Here is the code: Did anything else change besides the move to UDO from Illustra? For example did the string message being transmitted get longer or somesuch? The reason I ask is that your error checking is not very robust for a network communication function. You check if the number of characters written is < the string length and consider that an error. Often in a network app. it is necessary to determine how many characters were successfully written and restart the write from the next character unless an I/O error has been reported. This can be caused by anything from the target machine using a different packet size than another target machine to the write having been interrupted by a signal arriving to opening the network connection with O_NDELAY and O_NONBLOCK. Here is pseudocode for more robust communications: n_to_write = len(message) msgpos = 0 while (n_to_write > 0) do nwritten = write ( &message[msgpos], n_to_write ) if (nwritten == -1 && errno != EINTR) then # Most errno values indicate fatal errors. Values like # EAGAIN which would need the same kind of recovery as # a partial write only occurs when writing to a local # pipe (named or unnamed) or to a UNIX domain socket # (which is implemented as a named pipe). This would # be treated the same as EINTR below. exit while elseif (nwritten == -1 && errno == EINTR) then # It is best to use BSD style signal handling so that # the write system call automatically completes and this # errno is not returned since using System V signal # handling you cannot determine how many bytes, if any, # were actually written. nwritten = 0 endif n_to_write -= nwritten msgpos += nwritten endwhile Check out "UNIX Network Programming" by W. Richard Stevens for the most complete discussion of the pitfalls of error handling during network communications. Art S. Kagel