Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Read file untill EOT in client server programming
Forum Updated to NodeBB v4.3 + New Features

Read file untill EOT in client server programming

Scheduled Pinned Locked Moved Unsolved General and Desktop
13 Posts 3 Posters 1.8k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • H hjohn

    @JonB "EOT is 0x04.
    "Can i use any alternative of readALL() or after receiving all data using readall().I separate them by checking whether it contains EOT or not.if so then up to that marker store data into one file and another data into second file.

    JonBJ Offline
    JonBJ Offline
    JonB
    wrote on last edited by JonB
    #4

    @hjohn
    OK, so you're using the UNIX ^D to terminate your files.

    And you're actually explicitly sending that character from client to server at the end of each file, right?

    So all you can rely is that somewhere in the blocks returned from readAll() there will be an 0x04 every so often, but not necessarily right at the end of a "chunk" received. You must search the whole of the text for that character, not just the end of it. Furthermore, it might be that that a single read actually returns multiple files each separated by their 0x04s in one go, so you must loop to (potentially) pick out each separator.

    H 1 Reply Last reply
    2
    • VRoninV Offline
      VRoninV Offline
      VRonin
      wrote on last edited by VRonin
      #5

      Not perfect (only works if all the data is ASCII chars and it's hugely inefficient) but gives you an idea

      socket.startTransaction();
      QByteArray alldata = socket.readAll();
      socket.rollbackTransaction();
      int lastValidEOT=-1;
      for(int eotIndex = alldata.indexOf((char)4);eotIndex >= 0;eotIndex = alldata.indexOf((char)4)){
          lastValidEOT=eotIndex
          B = alldata.left(eotIndex);
          alldata.remove(0,eotIndex+1);
          qDebug() << B;
      }
      if(lastValidEOT>=0)
          socket.skip(lastValidEOT+1);
      

      Edit: efficiency improved

      "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
      ~Napoleon Bonaparte

      On a crusade to banish setIndexWidget() from the holy land of Qt

      H 1 Reply Last reply
      3
      • VRoninV VRonin

        Not perfect (only works if all the data is ASCII chars and it's hugely inefficient) but gives you an idea

        socket.startTransaction();
        QByteArray alldata = socket.readAll();
        socket.rollbackTransaction();
        int lastValidEOT=-1;
        for(int eotIndex = alldata.indexOf((char)4);eotIndex >= 0;eotIndex = alldata.indexOf((char)4)){
            lastValidEOT=eotIndex
            B = alldata.left(eotIndex);
            alldata.remove(0,eotIndex+1);
            qDebug() << B;
        }
        if(lastValidEOT>=0)
            socket.skip(lastValidEOT+1);
        

        Edit: efficiency improved

        H Offline
        H Offline
        hjohn
        wrote on last edited by
        #6

        @VRonin hey thanks..I will try.

        1 Reply Last reply
        0
        • JonBJ JonB

          @hjohn
          OK, so you're using the UNIX ^D to terminate your files.

          And you're actually explicitly sending that character from client to server at the end of each file, right?

          So all you can rely is that somewhere in the blocks returned from readAll() there will be an 0x04 every so often, but not necessarily right at the end of a "chunk" received. You must search the whole of the text for that character, not just the end of it. Furthermore, it might be that that a single read actually returns multiple files each separated by their 0x04s in one go, so you must loop to (potentially) pick out each separator.

          H Offline
          H Offline
          hjohn
          wrote on last edited by
          #7

          @JonB yeah i have applied same way as u have suggested.
          But Instead of getting all files into buffer chunk, I want to receive it one by one into buffer.

          JonBJ 1 Reply Last reply
          0
          • H Offline
            H Offline
            hjohn
            wrote on last edited by
            #8

            In the another thing i want your help is,I am sending file's data continuously to server from client.when STOP button clicked,It should stop sending file's data.
            I am sending initially 1000 files data.Before I press STOP button the process of sending files's data has already completed.so,I want to send data after some amount of time so I get a chance to press STOP button.what should i applied?

            JonBJ 1 Reply Last reply
            0
            • H hjohn

              @JonB yeah i have applied same way as u have suggested.
              But Instead of getting all files into buffer chunk, I want to receive it one by one into buffer.

              JonBJ Offline
              JonBJ Offline
              JonB
              wrote on last edited by
              #9

              @hjohn said in Read file untill EOT in client server programming:

              But Instead of getting all files into buffer chunk, I want to receive it one by one into buffer.

              Then you'd better write to Mr TCP/IP/socket and tell him you don't like the way it works and would like him to change the design :)

              TCP/IP/sockets use a continuous-streaming protocol, without record boundaries, so you can't have it your way, I'm afraid. You have two choices:

              • Current way. It really isn't too difficult to recognise these ^D boundaries and split into separate files on that basis. You even have @VRonin's clever but lazy way of doing it to reduce the code you need.

              • You change your protocol between client & server such that after sending one file (terminated by the ^D) the client sends an "acknowledgement" message back to the server; the server waits for that before starting to send the next file. This way the client sees its buffer only ever filled with one file, it never sees a second file till it has finished with the previous file. Now you can use your original while(!B.endswith(EOT)). This approach is a touch slower, if you were sending a large number of small files.

              H 1 Reply Last reply
              3
              • JonBJ JonB

                @hjohn said in Read file untill EOT in client server programming:

                But Instead of getting all files into buffer chunk, I want to receive it one by one into buffer.

                Then you'd better write to Mr TCP/IP/socket and tell him you don't like the way it works and would like him to change the design :)

                TCP/IP/sockets use a continuous-streaming protocol, without record boundaries, so you can't have it your way, I'm afraid. You have two choices:

                • Current way. It really isn't too difficult to recognise these ^D boundaries and split into separate files on that basis. You even have @VRonin's clever but lazy way of doing it to reduce the code you need.

                • You change your protocol between client & server such that after sending one file (terminated by the ^D) the client sends an "acknowledgement" message back to the server; the server waits for that before starting to send the next file. This way the client sees its buffer only ever filled with one file, it never sees a second file till it has finished with the previous file. Now you can use your original while(!B.endswith(EOT)). This approach is a touch slower, if you were sending a large number of small files.

                H Offline
                H Offline
                hjohn
                wrote on last edited by
                #10

                @JonB yeah U r right.

                @hjohn said in Read file untill EOT in client server programming:

                In the another thing i want your help is,I am sending file's data continuously to server from client.when STOP button clicked,It should stop sending file's data.
                I am sending initially 1000 files data.Before I press STOP button the process of sending files's data has already completed.so,I want to send data after some amount of time so I get a chance to press STOP button.what should i applied?

                Can u help me on this!!

                1 Reply Last reply
                0
                • H hjohn

                  In the another thing i want your help is,I am sending file's data continuously to server from client.when STOP button clicked,It should stop sending file's data.
                  I am sending initially 1000 files data.Before I press STOP button the process of sending files's data has already completed.so,I want to send data after some amount of time so I get a chance to press STOP button.what should i applied?

                  JonBJ Offline
                  JonBJ Offline
                  JonB
                  wrote on last edited by JonB
                  #11

                  @hjohn said in Read file untill EOT in client server programming:

                  I want to send data after some amount of time so I get a chance to press STOP button.what should i applied?

                  Now this does get tricky, precisely because of the continuous streaming protocol. There isn't really a "natural" way to do this, you have write code to implement whatever you want. I see 3 possibilities:

                  • I've never had to do it myself, but I believe the way you can do this is that sockets support something called an "out-of-band" ("OOB") message, which your client can send to your server. I do not know whether Qt's functions support this (haven't looked). This is a message which gets through on a separate channel ahead of any data already sent. Your server sees this and (you write code so that it) abandons receiving from the client.

                  • If you can afford to, you only check for "STOP" at the server between each complete file send. If pressed, you don't send the next file, so there are no "incomplete file sends". Of course, this means that "STOP" is not acted upon immediately. If your files are small this may be OK; but if you were in the middle of sending a huge file there would be a considerable delay while that one finished sending before the transfer gets terminated.

                  • You are already using a special character of ^D to mark the boundary between files. You assume that character can never occur in the data. You could extend this to pick another special character which the server sends on "STOP", say ^Z or \000 or something. Now your server, which is already scanning for the ^Ds, also checks whether the latest character is that special "STOP" marker, and abandons if it sees it. In principle this protocol is "instantaneous", there is no delay.

                  H 1 Reply Last reply
                  0
                  • JonBJ JonB

                    @hjohn said in Read file untill EOT in client server programming:

                    I want to send data after some amount of time so I get a chance to press STOP button.what should i applied?

                    Now this does get tricky, precisely because of the continuous streaming protocol. There isn't really a "natural" way to do this, you have write code to implement whatever you want. I see 3 possibilities:

                    • I've never had to do it myself, but I believe the way you can do this is that sockets support something called an "out-of-band" ("OOB") message, which your client can send to your server. I do not know whether Qt's functions support this (haven't looked). This is a message which gets through on a separate channel ahead of any data already sent. Your server sees this and (you write code so that it) abandons receiving from the client.

                    • If you can afford to, you only check for "STOP" at the server between each complete file send. If pressed, you don't send the next file, so there are no "incomplete file sends". Of course, this means that "STOP" is not acted upon immediately. If your files are small this may be OK; but if you were in the middle of sending a huge file there would be a considerable delay while that one finished sending before the transfer gets terminated.

                    • You are already using a special character of ^D to mark the boundary between files. You assume that character can never occur in the data. You could extend this to pick another special character which the server sends on "STOP", say ^Z or \000 or something. Now your server, which is already scanning for the ^Ds, also checks whether the latest character is that special "STOP" marker, and abandons if it sees it. In principle this protocol is "instantaneous", there is no delay.

                    H Offline
                    H Offline
                    hjohn
                    wrote on last edited by
                    #12

                    @JonB I have implemented for large amount of files(1000).In this case,when I clicked STOP button of client GUI,I works only after sending 1000 files.
                    Not working immediately.

                    JonBJ 1 Reply Last reply
                    0
                    • H hjohn

                      @JonB I have implemented for large amount of files(1000).In this case,when I clicked STOP button of client GUI,I works only after sending 1000 files.
                      Not working immediately.

                      JonBJ Offline
                      JonBJ Offline
                      JonB
                      wrote on last edited by
                      #13

                      @hjohn
                      I have offered you 3 approaches above which will work. You need to implement one of them.

                      Just to be clear: because you need to see the "STOP" when it's pressed, depending on your implementation you may need the client's file transfer to be taking place in its own thread, so that the main GUI thread (where "STOP" gets recognised) does not get blocked by the socket transfer.

                      1 Reply Last reply
                      0

                      • Login

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups
                      • Search
                      • Get Qt Extensions
                      • Unsolved