Over TCP communication in C, how can you indicate to stop calling read() for a request without knowing any...












0















I am currently programming a server in C that communicates over sockets using TCP. The client is supposed to send {filenamen} + {file contentsn} and the server will store that information and then send a response on success. However, we can't be sure the client will actually send the proper information in a structured protocol.



Often in simpler situations, we know a specified amount of bytes to be sent before and can wait until that specified number has been reached. In this case, we don't and currently the code looks like this:



//buffer is a resize-able array, 
//assume it's correct + don't worry about memory leakage for now
resizeablearray_t *buffer;

char data[255];
char retry = 1;
while (retry) {
int bytes = read(socketfd, data, 255);
if (bytes <= 0) {
fprintf(stderr, "Error %sn", strerror(errno));
return;
}
push(buffer, data, bytes);
}


Therefore, we're given a huge problem: how do we indicate to the read() function in c that we've read in all the information on the prior call and we shouldn't call it again?



The read() function blocks until there are bytes to be read over the server. However, in our model, if we continue to attempt to read due to short counts and there is nothing left in the buffer, we will wait FOREVER.



Any ideas on how to indicate before another read() call, without any prior information on the incoming message and its structure, that we can break from the while loop and stop attempting to read from the socket?










share|improve this question























  • You need to examine the contents of the data array and see if you received the terminator. Using n as the terminator for the filename is fine, since filenames don't contain n characters. For the file contents, I would use as the terminator, assuming the contents are text. For a binary file, you need to send the length, or base64 encode the contents.

    – user3386109
    Nov 29 '18 at 0:52











  • There are different ways to do this, but what about sending: filenamen file_size_in_bytesn file_contents since the client will/can know the file size before starting? What precludes this in your application?

    – Craig Estey
    Nov 29 '18 at 0:52













  • suggest using a select() statement with a timeout. However, note that if the returned count from read() is 0 that means the other end of the connection has hungup.BTW: the returned type from read() is NOT int but rather: ssize_t

    – user3629249
    Nov 29 '18 at 0:53













  • read() returning -1 is not an error. EAGAIN

    – wildplasser
    Nov 29 '18 at 1:28
















0















I am currently programming a server in C that communicates over sockets using TCP. The client is supposed to send {filenamen} + {file contentsn} and the server will store that information and then send a response on success. However, we can't be sure the client will actually send the proper information in a structured protocol.



Often in simpler situations, we know a specified amount of bytes to be sent before and can wait until that specified number has been reached. In this case, we don't and currently the code looks like this:



//buffer is a resize-able array, 
//assume it's correct + don't worry about memory leakage for now
resizeablearray_t *buffer;

char data[255];
char retry = 1;
while (retry) {
int bytes = read(socketfd, data, 255);
if (bytes <= 0) {
fprintf(stderr, "Error %sn", strerror(errno));
return;
}
push(buffer, data, bytes);
}


Therefore, we're given a huge problem: how do we indicate to the read() function in c that we've read in all the information on the prior call and we shouldn't call it again?



The read() function blocks until there are bytes to be read over the server. However, in our model, if we continue to attempt to read due to short counts and there is nothing left in the buffer, we will wait FOREVER.



Any ideas on how to indicate before another read() call, without any prior information on the incoming message and its structure, that we can break from the while loop and stop attempting to read from the socket?










share|improve this question























  • You need to examine the contents of the data array and see if you received the terminator. Using n as the terminator for the filename is fine, since filenames don't contain n characters. For the file contents, I would use as the terminator, assuming the contents are text. For a binary file, you need to send the length, or base64 encode the contents.

    – user3386109
    Nov 29 '18 at 0:52











  • There are different ways to do this, but what about sending: filenamen file_size_in_bytesn file_contents since the client will/can know the file size before starting? What precludes this in your application?

    – Craig Estey
    Nov 29 '18 at 0:52













  • suggest using a select() statement with a timeout. However, note that if the returned count from read() is 0 that means the other end of the connection has hungup.BTW: the returned type from read() is NOT int but rather: ssize_t

    – user3629249
    Nov 29 '18 at 0:53













  • read() returning -1 is not an error. EAGAIN

    – wildplasser
    Nov 29 '18 at 1:28














0












0








0








I am currently programming a server in C that communicates over sockets using TCP. The client is supposed to send {filenamen} + {file contentsn} and the server will store that information and then send a response on success. However, we can't be sure the client will actually send the proper information in a structured protocol.



Often in simpler situations, we know a specified amount of bytes to be sent before and can wait until that specified number has been reached. In this case, we don't and currently the code looks like this:



//buffer is a resize-able array, 
//assume it's correct + don't worry about memory leakage for now
resizeablearray_t *buffer;

char data[255];
char retry = 1;
while (retry) {
int bytes = read(socketfd, data, 255);
if (bytes <= 0) {
fprintf(stderr, "Error %sn", strerror(errno));
return;
}
push(buffer, data, bytes);
}


Therefore, we're given a huge problem: how do we indicate to the read() function in c that we've read in all the information on the prior call and we shouldn't call it again?



The read() function blocks until there are bytes to be read over the server. However, in our model, if we continue to attempt to read due to short counts and there is nothing left in the buffer, we will wait FOREVER.



Any ideas on how to indicate before another read() call, without any prior information on the incoming message and its structure, that we can break from the while loop and stop attempting to read from the socket?










share|improve this question














I am currently programming a server in C that communicates over sockets using TCP. The client is supposed to send {filenamen} + {file contentsn} and the server will store that information and then send a response on success. However, we can't be sure the client will actually send the proper information in a structured protocol.



Often in simpler situations, we know a specified amount of bytes to be sent before and can wait until that specified number has been reached. In this case, we don't and currently the code looks like this:



//buffer is a resize-able array, 
//assume it's correct + don't worry about memory leakage for now
resizeablearray_t *buffer;

char data[255];
char retry = 1;
while (retry) {
int bytes = read(socketfd, data, 255);
if (bytes <= 0) {
fprintf(stderr, "Error %sn", strerror(errno));
return;
}
push(buffer, data, bytes);
}


Therefore, we're given a huge problem: how do we indicate to the read() function in c that we've read in all the information on the prior call and we shouldn't call it again?



The read() function blocks until there are bytes to be read over the server. However, in our model, if we continue to attempt to read due to short counts and there is nothing left in the buffer, we will wait FOREVER.



Any ideas on how to indicate before another read() call, without any prior information on the incoming message and its structure, that we can break from the while loop and stop attempting to read from the socket?







c network-programming blocking readblock






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 29 '18 at 0:37









tpstps

1




1













  • You need to examine the contents of the data array and see if you received the terminator. Using n as the terminator for the filename is fine, since filenames don't contain n characters. For the file contents, I would use as the terminator, assuming the contents are text. For a binary file, you need to send the length, or base64 encode the contents.

    – user3386109
    Nov 29 '18 at 0:52











  • There are different ways to do this, but what about sending: filenamen file_size_in_bytesn file_contents since the client will/can know the file size before starting? What precludes this in your application?

    – Craig Estey
    Nov 29 '18 at 0:52













  • suggest using a select() statement with a timeout. However, note that if the returned count from read() is 0 that means the other end of the connection has hungup.BTW: the returned type from read() is NOT int but rather: ssize_t

    – user3629249
    Nov 29 '18 at 0:53













  • read() returning -1 is not an error. EAGAIN

    – wildplasser
    Nov 29 '18 at 1:28



















  • You need to examine the contents of the data array and see if you received the terminator. Using n as the terminator for the filename is fine, since filenames don't contain n characters. For the file contents, I would use as the terminator, assuming the contents are text. For a binary file, you need to send the length, or base64 encode the contents.

    – user3386109
    Nov 29 '18 at 0:52











  • There are different ways to do this, but what about sending: filenamen file_size_in_bytesn file_contents since the client will/can know the file size before starting? What precludes this in your application?

    – Craig Estey
    Nov 29 '18 at 0:52













  • suggest using a select() statement with a timeout. However, note that if the returned count from read() is 0 that means the other end of the connection has hungup.BTW: the returned type from read() is NOT int but rather: ssize_t

    – user3629249
    Nov 29 '18 at 0:53













  • read() returning -1 is not an error. EAGAIN

    – wildplasser
    Nov 29 '18 at 1:28

















You need to examine the contents of the data array and see if you received the terminator. Using n as the terminator for the filename is fine, since filenames don't contain n characters. For the file contents, I would use as the terminator, assuming the contents are text. For a binary file, you need to send the length, or base64 encode the contents.

– user3386109
Nov 29 '18 at 0:52





You need to examine the contents of the data array and see if you received the terminator. Using n as the terminator for the filename is fine, since filenames don't contain n characters. For the file contents, I would use as the terminator, assuming the contents are text. For a binary file, you need to send the length, or base64 encode the contents.

– user3386109
Nov 29 '18 at 0:52













There are different ways to do this, but what about sending: filenamen file_size_in_bytesn file_contents since the client will/can know the file size before starting? What precludes this in your application?

– Craig Estey
Nov 29 '18 at 0:52







There are different ways to do this, but what about sending: filenamen file_size_in_bytesn file_contents since the client will/can know the file size before starting? What precludes this in your application?

– Craig Estey
Nov 29 '18 at 0:52















suggest using a select() statement with a timeout. However, note that if the returned count from read() is 0 that means the other end of the connection has hungup.BTW: the returned type from read() is NOT int but rather: ssize_t

– user3629249
Nov 29 '18 at 0:53







suggest using a select() statement with a timeout. However, note that if the returned count from read() is 0 that means the other end of the connection has hungup.BTW: the returned type from read() is NOT int but rather: ssize_t

– user3629249
Nov 29 '18 at 0:53















read() returning -1 is not an error. EAGAIN

– wildplasser
Nov 29 '18 at 1:28





read() returning -1 is not an error. EAGAIN

– wildplasser
Nov 29 '18 at 1:28












2 Answers
2






active

oldest

votes


















2














In modern file transfer protocols, there is an indication of the size of the file, or more directly, how many bytes in the payload of the transaction. This allows the other side to know how many bytes will be delivered. If not enough bytes are delivered, the reader needs to keep reading. When all the bytes are delivered, there is no "extra" call to read in the sense you are asking about.



Even if the sender is creating data dynamically, and thus doesn't know how many bytes are going to be sent in total at the beginning of the transaction, it can at least report how many bytes are being delivered in the current send. When it is done, it can send a final report that indicates it is done sending. The receiver reads until it sees this final report.



If you use the recv call instead of read, you will be able to pass in flags to indicate that you do not wish to block waiting forever, and instead want an immediate status of whether there is anything left to read. However, this is an unreliable method to determine if the transfer is complete. The sender could just be slow, and the rest of the file may very well come some time later.






share|improve this answer































    1














    How about creating a [simple/crude] packet protocol between the two:



    byte_length(4)|data(byte_length)


    When done, sender sends one final packet with byte_length set to 0 (i.e. an EOF marker) to indicate all has been sent.



    Here's some rough code:



    //buffer is a resize-able array,
    //assume it's correct + don't worry about memory leakage for now
    resizeablearray_t *buffer;

    char data[255];
    char retry = 1;

    void
    receive(void)
    {
    uint32_t size;
    int bytes;

    while (retry) {

    bytes = read(socketfd,&size,sizeof(size));
    if (bytes <= 0) {
    fprintf(stderr, "Error %sn", strerror(errno));
    return;
    }

    // got EOF marker
    if (size == 0)
    break;

    size = ntohl(size);

    bytes = read(socketfd, data, size);
    if (bytes <= 0) {
    fprintf(stderr, "Error %sn", strerror(errno));
    return;
    }
    push(buffer, data, bytes);
    }
    }

    void
    sender(void)
    {
    uint32_t size;
    int bytes;

    while (retry) {

    bytes = read(filefd, data, sizeof(data));
    if (bytes == 0)
    break;

    if (bytes < 0) {
    fprintf(stderr, "Error %sn", strerror(errno));
    return;
    }

    size = htonl(bytes);
    bytes = write(socketfd, &size, sizeof(size));

    bytes = write(socketfd, data, bytes);
    if (bytes <= 0) {
    fprintf(stderr, "Error %sn", strerror(errno));
    return;
    }
    }

    // send EOF marker
    size = 0;
    write(socketfd,&size,sizeof(size));
    }





    share|improve this answer


























      Your Answer






      StackExchange.ifUsing("editor", function () {
      StackExchange.using("externalEditor", function () {
      StackExchange.using("snippets", function () {
      StackExchange.snippets.init();
      });
      });
      }, "code-snippets");

      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "1"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














      draft saved

      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53530184%2fover-tcp-communication-in-c-how-can-you-indicate-to-stop-calling-read-for-a-r%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      2














      In modern file transfer protocols, there is an indication of the size of the file, or more directly, how many bytes in the payload of the transaction. This allows the other side to know how many bytes will be delivered. If not enough bytes are delivered, the reader needs to keep reading. When all the bytes are delivered, there is no "extra" call to read in the sense you are asking about.



      Even if the sender is creating data dynamically, and thus doesn't know how many bytes are going to be sent in total at the beginning of the transaction, it can at least report how many bytes are being delivered in the current send. When it is done, it can send a final report that indicates it is done sending. The receiver reads until it sees this final report.



      If you use the recv call instead of read, you will be able to pass in flags to indicate that you do not wish to block waiting forever, and instead want an immediate status of whether there is anything left to read. However, this is an unreliable method to determine if the transfer is complete. The sender could just be slow, and the rest of the file may very well come some time later.






      share|improve this answer




























        2














        In modern file transfer protocols, there is an indication of the size of the file, or more directly, how many bytes in the payload of the transaction. This allows the other side to know how many bytes will be delivered. If not enough bytes are delivered, the reader needs to keep reading. When all the bytes are delivered, there is no "extra" call to read in the sense you are asking about.



        Even if the sender is creating data dynamically, and thus doesn't know how many bytes are going to be sent in total at the beginning of the transaction, it can at least report how many bytes are being delivered in the current send. When it is done, it can send a final report that indicates it is done sending. The receiver reads until it sees this final report.



        If you use the recv call instead of read, you will be able to pass in flags to indicate that you do not wish to block waiting forever, and instead want an immediate status of whether there is anything left to read. However, this is an unreliable method to determine if the transfer is complete. The sender could just be slow, and the rest of the file may very well come some time later.






        share|improve this answer


























          2












          2








          2







          In modern file transfer protocols, there is an indication of the size of the file, or more directly, how many bytes in the payload of the transaction. This allows the other side to know how many bytes will be delivered. If not enough bytes are delivered, the reader needs to keep reading. When all the bytes are delivered, there is no "extra" call to read in the sense you are asking about.



          Even if the sender is creating data dynamically, and thus doesn't know how many bytes are going to be sent in total at the beginning of the transaction, it can at least report how many bytes are being delivered in the current send. When it is done, it can send a final report that indicates it is done sending. The receiver reads until it sees this final report.



          If you use the recv call instead of read, you will be able to pass in flags to indicate that you do not wish to block waiting forever, and instead want an immediate status of whether there is anything left to read. However, this is an unreliable method to determine if the transfer is complete. The sender could just be slow, and the rest of the file may very well come some time later.






          share|improve this answer













          In modern file transfer protocols, there is an indication of the size of the file, or more directly, how many bytes in the payload of the transaction. This allows the other side to know how many bytes will be delivered. If not enough bytes are delivered, the reader needs to keep reading. When all the bytes are delivered, there is no "extra" call to read in the sense you are asking about.



          Even if the sender is creating data dynamically, and thus doesn't know how many bytes are going to be sent in total at the beginning of the transaction, it can at least report how many bytes are being delivered in the current send. When it is done, it can send a final report that indicates it is done sending. The receiver reads until it sees this final report.



          If you use the recv call instead of read, you will be able to pass in flags to indicate that you do not wish to block waiting forever, and instead want an immediate status of whether there is anything left to read. However, this is an unreliable method to determine if the transfer is complete. The sender could just be slow, and the rest of the file may very well come some time later.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 29 '18 at 0:58









          jxhjxh

          56.1k675148




          56.1k675148

























              1














              How about creating a [simple/crude] packet protocol between the two:



              byte_length(4)|data(byte_length)


              When done, sender sends one final packet with byte_length set to 0 (i.e. an EOF marker) to indicate all has been sent.



              Here's some rough code:



              //buffer is a resize-able array,
              //assume it's correct + don't worry about memory leakage for now
              resizeablearray_t *buffer;

              char data[255];
              char retry = 1;

              void
              receive(void)
              {
              uint32_t size;
              int bytes;

              while (retry) {

              bytes = read(socketfd,&size,sizeof(size));
              if (bytes <= 0) {
              fprintf(stderr, "Error %sn", strerror(errno));
              return;
              }

              // got EOF marker
              if (size == 0)
              break;

              size = ntohl(size);

              bytes = read(socketfd, data, size);
              if (bytes <= 0) {
              fprintf(stderr, "Error %sn", strerror(errno));
              return;
              }
              push(buffer, data, bytes);
              }
              }

              void
              sender(void)
              {
              uint32_t size;
              int bytes;

              while (retry) {

              bytes = read(filefd, data, sizeof(data));
              if (bytes == 0)
              break;

              if (bytes < 0) {
              fprintf(stderr, "Error %sn", strerror(errno));
              return;
              }

              size = htonl(bytes);
              bytes = write(socketfd, &size, sizeof(size));

              bytes = write(socketfd, data, bytes);
              if (bytes <= 0) {
              fprintf(stderr, "Error %sn", strerror(errno));
              return;
              }
              }

              // send EOF marker
              size = 0;
              write(socketfd,&size,sizeof(size));
              }





              share|improve this answer






























                1














                How about creating a [simple/crude] packet protocol between the two:



                byte_length(4)|data(byte_length)


                When done, sender sends one final packet with byte_length set to 0 (i.e. an EOF marker) to indicate all has been sent.



                Here's some rough code:



                //buffer is a resize-able array,
                //assume it's correct + don't worry about memory leakage for now
                resizeablearray_t *buffer;

                char data[255];
                char retry = 1;

                void
                receive(void)
                {
                uint32_t size;
                int bytes;

                while (retry) {

                bytes = read(socketfd,&size,sizeof(size));
                if (bytes <= 0) {
                fprintf(stderr, "Error %sn", strerror(errno));
                return;
                }

                // got EOF marker
                if (size == 0)
                break;

                size = ntohl(size);

                bytes = read(socketfd, data, size);
                if (bytes <= 0) {
                fprintf(stderr, "Error %sn", strerror(errno));
                return;
                }
                push(buffer, data, bytes);
                }
                }

                void
                sender(void)
                {
                uint32_t size;
                int bytes;

                while (retry) {

                bytes = read(filefd, data, sizeof(data));
                if (bytes == 0)
                break;

                if (bytes < 0) {
                fprintf(stderr, "Error %sn", strerror(errno));
                return;
                }

                size = htonl(bytes);
                bytes = write(socketfd, &size, sizeof(size));

                bytes = write(socketfd, data, bytes);
                if (bytes <= 0) {
                fprintf(stderr, "Error %sn", strerror(errno));
                return;
                }
                }

                // send EOF marker
                size = 0;
                write(socketfd,&size,sizeof(size));
                }





                share|improve this answer




























                  1












                  1








                  1







                  How about creating a [simple/crude] packet protocol between the two:



                  byte_length(4)|data(byte_length)


                  When done, sender sends one final packet with byte_length set to 0 (i.e. an EOF marker) to indicate all has been sent.



                  Here's some rough code:



                  //buffer is a resize-able array,
                  //assume it's correct + don't worry about memory leakage for now
                  resizeablearray_t *buffer;

                  char data[255];
                  char retry = 1;

                  void
                  receive(void)
                  {
                  uint32_t size;
                  int bytes;

                  while (retry) {

                  bytes = read(socketfd,&size,sizeof(size));
                  if (bytes <= 0) {
                  fprintf(stderr, "Error %sn", strerror(errno));
                  return;
                  }

                  // got EOF marker
                  if (size == 0)
                  break;

                  size = ntohl(size);

                  bytes = read(socketfd, data, size);
                  if (bytes <= 0) {
                  fprintf(stderr, "Error %sn", strerror(errno));
                  return;
                  }
                  push(buffer, data, bytes);
                  }
                  }

                  void
                  sender(void)
                  {
                  uint32_t size;
                  int bytes;

                  while (retry) {

                  bytes = read(filefd, data, sizeof(data));
                  if (bytes == 0)
                  break;

                  if (bytes < 0) {
                  fprintf(stderr, "Error %sn", strerror(errno));
                  return;
                  }

                  size = htonl(bytes);
                  bytes = write(socketfd, &size, sizeof(size));

                  bytes = write(socketfd, data, bytes);
                  if (bytes <= 0) {
                  fprintf(stderr, "Error %sn", strerror(errno));
                  return;
                  }
                  }

                  // send EOF marker
                  size = 0;
                  write(socketfd,&size,sizeof(size));
                  }





                  share|improve this answer















                  How about creating a [simple/crude] packet protocol between the two:



                  byte_length(4)|data(byte_length)


                  When done, sender sends one final packet with byte_length set to 0 (i.e. an EOF marker) to indicate all has been sent.



                  Here's some rough code:



                  //buffer is a resize-able array,
                  //assume it's correct + don't worry about memory leakage for now
                  resizeablearray_t *buffer;

                  char data[255];
                  char retry = 1;

                  void
                  receive(void)
                  {
                  uint32_t size;
                  int bytes;

                  while (retry) {

                  bytes = read(socketfd,&size,sizeof(size));
                  if (bytes <= 0) {
                  fprintf(stderr, "Error %sn", strerror(errno));
                  return;
                  }

                  // got EOF marker
                  if (size == 0)
                  break;

                  size = ntohl(size);

                  bytes = read(socketfd, data, size);
                  if (bytes <= 0) {
                  fprintf(stderr, "Error %sn", strerror(errno));
                  return;
                  }
                  push(buffer, data, bytes);
                  }
                  }

                  void
                  sender(void)
                  {
                  uint32_t size;
                  int bytes;

                  while (retry) {

                  bytes = read(filefd, data, sizeof(data));
                  if (bytes == 0)
                  break;

                  if (bytes < 0) {
                  fprintf(stderr, "Error %sn", strerror(errno));
                  return;
                  }

                  size = htonl(bytes);
                  bytes = write(socketfd, &size, sizeof(size));

                  bytes = write(socketfd, data, bytes);
                  if (bytes <= 0) {
                  fprintf(stderr, "Error %sn", strerror(errno));
                  return;
                  }
                  }

                  // send EOF marker
                  size = 0;
                  write(socketfd,&size,sizeof(size));
                  }






                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  edited Nov 29 '18 at 1:33

























                  answered Nov 29 '18 at 1:18









                  Craig EsteyCraig Estey

                  15.3k21131




                  15.3k21131






























                      draft saved

                      draft discarded




















































                      Thanks for contributing an answer to Stack Overflow!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid



                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.


                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53530184%2fover-tcp-communication-in-c-how-can-you-indicate-to-stop-calling-read-for-a-r%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      Contact image not getting when fetch all contact list from iPhone by CNContact

                      count number of partitions of a set with n elements into k subsets

                      A CLEAN and SIMPLE way to add appendices to Table of Contents and bookmarks