HI to All, I guess u cannot really go too far from JavaRanch, U Keep coming back to it. There are certain problems I am facing in using sockets. 1. Once i do a getInputStream() from a socket, do i need to explicitly close it before i close my socket? 2. What if i call socket.getInputStream() twice in my program, do i ve to make sure that the previous one is closed before i open the next one. 3. typically what exactly means by closing the inputStream of a socket. I hope i am not sending any FIN to my peer to close down the socket. 4. Now this problem is more intricate. So all the Java Networking gurus.. Hold ur breadth. My clients ( possibly many 100's for example) will connect to my TCP server thread that blocks on "accept". Now i dont want to create a new thread for each accepted socket (to do the communication with the client). hence i created a TCP Communication thread(TCPComm class) that maintains a List of sockets that have been "accepted" by the TCP server.My TCPComm thread tries to read the sockets in the List in a for loop ( each socket setSoTimeout has been 1 msec- to make it nonblocking ).
My clients will write to the connected socket, and the data that they write will vary in length. Now the TCPComm tries to read the Header the client writes which contains the size of the data coming Your way. Now my problem is : If suppose i m unable to read the full data, I will somehow have to remember what all data has been read and how much is still to come for each socket(client). Now kindly let me know How to approach this problem. Shud i use DataInputStream and use the mark and reset mechanisms given by these streams. or explicitly code for remembering how much i ve already read and how much is tsill to come in my buffer?
Hi, I can't answer all your questions but I can give it a go (answers apply to JDK1.3.1) 1) No you don't need to explicitly close it, but, generally closing the InputStream closes the socket, and vice-versa 2) You get an Inputstream for that socket, from the point where your previous getInputStream() finished with it.
I have no java certifications. This makes me a bad programmer. Ignore my post.
4. Now this problem is more intricate. So all the Java Networking gurus.. Hold ur breadth. My clients ( possibly many 100's for example) will connect to my TCP server thread that blocks on "accept". Now i dont want to create a new thread for each accepted socket (to do the communication with the client).
Why don't you want to create a new thread for accepted connection? This seems to be a simpler approach than attempting to keep track of what you have or have not yet read, and the for loop structure disappears as well. I'm not saying it can't or shouldn't be done. Guess I'm curious what your reasoning is.
posted 17 years ago
My only reply for not creating a separate thread for each connection is efficiency. In my opinion creating a separate Thread for Each Connection will be very processor and resource Intensive. The reality is I want to do this as an exercise, I will create 100 threads and see the performance of my application. and I will do the same thing using one thread.
hello Amit sir
I am also trying to make multiple client chat without using and running multiple Threads.
Your answer is too impresive about threads and efficiency. Would you please tell me what you have done with the same.
...maybe it helps extending your custom protocol by some session identifier. Doing so, would allow you to identitify a Client even if it reconnects to the server. In this session you could hold information on current jobs, data required by a current job and so on.
of course you would also need some mechanism to get rid of sessions, as this approach does not guarantee that a client is done with its work as it disconnects. Usually this is done by explicit closing a session (exit application) or a scheduled-job, 'killing' orphaned session (eg. session open > 15min as default)
It's never done THAT before. Explain it to me tiny ad:
Two software engineers solve most of the world's problems in one K&R sized book