Variable length Send and Receive commands (ISeries to .Net)

I must disagree with helianthus87. Socket datagram lengths do *not* have to be constant, and therein lies the issue. Consider a socket connection to be a stream, or pipe whose other end happens to be miles away. You need to package your data with either some delimiter(s) you can recognise when scanning the stream or a header that includes a length field. Transmission is easy - just package the message data with header or delimiter(s) and send. The socket implementation will take care of chopping it up into transmission units if necessary (or even welding together adjacent little chunks). On the receive side, how to do it depends on which option you chose above. For delimited, the basic process is:

while (data_available(socket))
  {
  read a byte and append to local buffer;
  if it was a end-of-message mark
    process the buffered message;
  }

For length-delimited:

for (length_of_header)
  read a byte into header buffer;
for (length_of_rest_of_message)
  read a byte into message buffer;
process message;

My personal preference is for length-delimited, for a couple of reasons:
1. It's data transparent. You don't have to make sure your data stream doesn't include whatever you've chosen as a delimiter.[1]
2. Once you've got a header, you will find all sorts of other things you can usefully put there.

Cheers,
Peter

[1] Many many years ago (mid '70s) I worked on a message switch for a major airline. Their telex replacement used torn-tape message delimiting: NNNN = end of message, ZCZC = start of message. That all worked brilliantly until the Polish Symphony Orchestra went on a world tour! :laugh:

[edit] had start and end swapped. It's been a while...[/edit]

[@helianthus87] From the original question, I thought the OP had the I-series side working, and just needed something to tell his .NET colleagues. I could go on about blocking and non-blocking sockets and all sorts of such, but {my} life's too short. :)

Remember to vote, and accept good answers.