Solved Java Socket Problem

Discussion in 'Plugin Development' started by mazentheamazin, Jun 17, 2014.

Thread Status:
Not open for further replies.
  1. Offline

    mazentheamazin

    Hi,

    I am currently working on a Notifier plugin and using Sockets for communication between a client and the server, as of right now I am running into a problem. Currently, there are nothing being written to the output stream or nothing being received through the input stream, you will see what I mean when I show you the code.

    The whole plugin is open-source, so feel free to look around here. (NotifierServer.java)

    The test client I am using to test this is here.

    If you look at line 41 of NotifierClient.java (Test client) you can see that I write a string to the output stream, and listen for it on line 40 of NotifierServer.java. Yet nothing is rather received or written. I'm pretty stumped here, and I thought some of you could help resolve my problem.

    Any help is appreciated,
    Mazen K.
     
  2. Offline

    Rocoty

    You forgot to start the thread in NotifierServer.java

    Actually nvm. I thought that was the only class
     
  3. Offline

    gjossep

    mazentheamazin Hmm, add some debug statements in both the Client and the server. Are you sure they are connecting? It could be that the server did not reconize that a client connected, and might be still at the socket.accpet stage.
     
  4. Offline

    mazentheamazin

    gjossep
    I had debug statements, it accepts the socket, and creates the input and output streams, but its stuck on 'readUTF'. On the client, it connects and sends the UTF string, but then is stuck waiting for a reply from the server.
     
  5. Offline

    gjossep

    mazentheamazin Alright good, just wanted to confirm. It seems to be in the server code then. Have you already tried to get the UTF string without spliting directly?
     
  6. Offline

    garbagemule

    First of all, you are only making things worse for yourself by not providing an SSCCE. No one wants to read through several classes to find a tiny bug in your system, so condense the problem space so people can read exactly what's relevant, nothing more, nothing less. This is also the most important rule of debugging, so if you take anything away from my post, let it be that you should NEVER continue to debug complex code, when condensing and simplifying it is trivial (which it is in this case). Humans are very, very bad at reasoning about huge problem spaces, and indeed, one of the most fundamental principles of computer science is "continue breaking the problem down into smaller chunks, until all chunks are managable".

    As for your actual problem, I think you would benefit from reading up on streams (if you think streams are "just a series of bits and bytes", you don't know what streams are). Knowing what streams actually are and how they are handled at the slightly lower levels will help you understand how to use them correctly.

    Happy hacking! :)

    PS: There is a perfectly logical reason for the blocking you're experiencing. Try to see if you can figure out why by reasoning about the states of the two threads (client and server); when and why do they block, and why do they not continue execution?
     
    mazentheamazin likes this.
  7. Offline

    mazentheamazin

    It was due to the fact that I wasn't flushing the output stream, I only buffered the data, however, did not flush it.
     
  8. Offline

    garbagemule

    This is true, but it is only part of the reason. From the classic "server/client" communication model where a server sends (serves) data, and a client receives (requests) it, none of your two classes are actually one or the other. Both of your classes can be considered "servents", because both classes request and send information.

    The blocking happens because after you have written data to the output stream from the client side, you call a read-method, which blocks until data is available. On the server side, you started out by calling a read-method, but because you never flushed (bonus info: closing a stream [usually] also flushes its buffers) on the client side, the server side stays blocked. Thus, the server side never reaches its own write-method, because it keeps waiting for the data that sits in the output buffer, and the client keeps waiting for The Data That Never Comes.

    As a final note, I'd like to advise you against calling any methods directly on the output from a read-method when working with sockets. You don't know what might come out, so you should program defensively. Assume that someone will send a null value or invalid String, and handle those cases via normal control-statements rather than generic exception clauses - remember that checked exceptions (the ones you catch) need to be caught because they can happen for unforseeable reasons, whereas unchecked exceptions (e.g. NPEs) happen because of reckless/unaware/stupid programmers ;)
     
    mazentheamazin likes this.
  9. Offline

    mazentheamazin

    On client side, I initially buffered data to the output stream, however, I didn't flush, thus causing both threads to be blocked.

    'The Data That Never Comes" I actually had a laugh at that one, nice pun :)
     
    garbagemule likes this.
Thread Status:
Not open for further replies.

Share This Page