0

my todays problem is the following:

I have a network connection, at which both sides have to send commands (bytes), but my reader blocks my writer, thats how it seems to be. If I "disable" my reader (by deleting the reader from source) the writer works as he should, But when my reader is there, too, my writer just do the half of the work.

Lets say my writer has to send a command with an interval of 15 seconds and stay aware of incoming commands whach has to be answered by a little byte block. The answer block is send, but the command from the interval seems blocked.

Here my source:

    protected String doInBackground(URL... params) {
        try {
            btw1 = (byte) sendbeg;
            btw2 = (byte) w2;
            btw3 = (byte) w3;
            btw4 = (byte) w4;
            btw5 = (byte) w5;
            if (w5 == 79) {
                btw6 = (byte) mins;
                btw7 = (byte) seks;
                btw8 = (byte) w6;
                btw9 = (byte) sendend;
            } else {
                btw6 = (byte) w6;
                btw7 = (byte) sendend;
            }
            SocketAddress sockaddr = new InetSocketAddress("192.168.0.7", 2001);
            sock = new Socket();
            int timeout = 1000; // 1000 millis = 1 second
            sock.connect(sockaddr, timeout);
            sock.setReuseAddress(true);
            System.out.println(sock);
            DataOutputStream dos = new DataOutputStream(
                    (OutputStream) sock.getOutputStream());
            BufferedWriter wrtr = new BufferedWriter(
                    new OutputStreamWriter(dos), 300);
            DataInputStream dis = new DataInputStream(sock.getInputStream());
            BufferedReader rdr = new BufferedReader(new InputStreamReader(dis),
                    300);
            getbyte((byte) btw1, (byte) btw2, (byte) btw3, (byte) btw4,
                    (byte) btw5, (byte) btw6, (byte) btw7, (byte) btw8,
                    (byte) btw9, (byte) btw10); //getbyte works fine, too. It's just there for putting the single bytes into an array.
            System.out.println(btw.length);
            dos.write(btw);
            diny1 = (dis).read();           
diny2 = (dis).read();           
diny3 = (dis).read();           
diny4 = (dis).read();

            diny5 = (dis).read();           
dinymin = (dis).read();
            dinysek = (dis).read();
            diny6 = (dis).read();
            diny7 = (dis).read();
            if (diny5 != 79) {
                System.out.println("diny" + diny1 + " " + diny2 + " " + diny3
                        + " " + diny4 + " " + diny5 + " " + dinymin + " "
                        + dinysek);
            } else {
                if (diny7 != 5) {
                    diny6 = 0;
                    diny7 = 0;
                }
                System.out.println("diny" + diny1 + " " + diny2 + " " + diny3
                        + " " + diny4 + " " + diny5 + " " + dinymin + " "
                        + dinysek + " " + diny6 + " " + diny7);
            }
            dos.close();
            wrtr.close();
            dis.close();
            rdr.close();
            if (diny5 != 32) {
                sendbeg = 3;
                w2 = diny3;
                w3 = diny2;
                w4 = 48;
                w5 = 32;
                w6 = 11;
                sendend = 5;
                System.out.println(diny5 + " ^^ ");
                doInBackground();

            }
            System.out.println("case 144-49-000.1" + context);
            reccom(context);
            sock.close();

        } catch (Exception e) {
            e.printStackTrace();

            System.out.println("IO error " + e);
        }

        return "Done";
    }

My intervalsource works fine, because it works, if the reader is inactive, so i think the problem is in this code above. please help.

Eveli
  • 498
  • 1
  • 6
  • 27

1 Answers1

1
  • You can delete the setReuseAddress() call; it's only for server sockets.
  • AsyncTask is not exactly the right class for your readers and writers if you stay in a loop there all the time; it would be more suitable to use Thread.
  • It sounds as if you need a seperate reader and writer Thread if one is not allowed to block the other.
  • You'll probably have to use synchronized along the way if reader and writer act independently
class stacker
  • 5,357
  • 2
  • 32
  • 65
  • hmm thx so far, i have no experience in using threads, so this will become a little difficult i think. I'll regard your hints – Eveli Feb 19 '13 at 07:29
  • The biggest challenge will be to distinguish between responses and commands on the receiving side I guess; you'll need a kind of state machine there I would assume. Using threads is easy; just set up a Runnable object (a class with a run() method) and don't fortet to start them. The problems with threads: Data synchronization (receiver and sender can potentially run in parallel) and termination (when your activity stops, your Threads must know this). – class stacker Feb 19 '13 at 07:42
  • hope you're right by "using threads is easy" ^^ but you already helped me with that. Now i will bully the developer-site of developer.android.com a little bit ^^ – Eveli Feb 19 '13 at 07:46
  • @Ekonion To be honest, I think you still don't think in a way such that you understand concurrency, multithreading and such -- judging from your question(s). But apart from that, setting up a Thread is easy, and you can ignore shutting it down gracefully for now. ;) -- If I understand your project correctly, I'd set up a shared "CommState" object which is `synchronized`, and the sender would register there whether or not it is currently expecting a response or not. – class stacker Feb 19 '13 at 08:18
  • To be honest, you're right. I just began with android in November on my own, getting pressure from my boss and noone who could explain anything. It`s still hard to me to understand even the basics. Most of the time i am kind of puzzling around and hope it works. The only thing i learned till now is HTML, but that is not object-oriented. What do you exactly mean by a shared CommState? sth like a status bit which says if a command came in or not? – Eveli Feb 19 '13 at 08:24
  • @Ekonion Okay so you don't know Java well, you're not familiar with multithreading, you're new to socket communication, and now I'm getting the impression you don't know much about state machines in the communication protocel environment... Also, the end-to-end protocol is confidential so you won't disclose it and I can't give specific suggestions... I must say I'm not sure how to go on from here. Although I could offer you to implement this rapidly (as a paid official project, that is). – class stacker Feb 19 '13 at 09:45
  • @Ekonion To answer your question: I have no idea what you'll need in such a shared object because I don't know the end-to-end protocol. Also, I don't know the robustness requirements, and I can also not take a guess, because I don't even know in which area of application your product will be placed. So that'll be up to you... – class stacker Feb 19 '13 at 09:47
  • im very thankful for your time and your answers. Im already on it, trying different things and experimenting a little bit with threads. I think i will get it soon. The fundament for my success is there now ^^ I will get the rest working, too ^^ is it okay to you, to ask more questions about threading when they come up? – Eveli Feb 19 '13 at 09:56
  • Yeah sure. But maybe you could _finally_ let us know explicitly whether or not your communication peer can send messages ("commands") even though you are waiting for a response to a message ("Command") which _you_ sent? Or what other asynchronous challenge do you face? – class stacker Feb 19 '13 at 10:07
  • okay, here what it has to do: I want to send a command to a machine, this answers with a 20. The machine sends me a command and i answer with a 20, too. Now what it does: the machine send sme a command and i am able to answer with a 20, but i cannot send any commands to the machine. They stuck anywhere. I can answer, but not command, btw i am the client, the machine the host. We may go to a chat.. that could be easier – Eveli Feb 19 '13 at 10:19
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/24756/discussion-between-ekonion-and-class-stacker) – Eveli Feb 19 '13 at 10:32