aspose file tools*
The moose likes Sockets and Internet Protocols and the fly likes Sockets, Multiple Clients, and i/o.....mind blowing!!! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Sockets and Internet Protocols
Bookmark "Sockets, Multiple Clients, and i/o.....mind blowing!!!" Watch "Sockets, Multiple Clients, and i/o.....mind blowing!!!" New topic
Author

Sockets, Multiple Clients, and i/o.....mind blowing!!!

Amit Saini
Greenhorn

Joined: Oct 17, 2000
Posts: 5
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?
Lewin Chan
Ranch Hand

Joined: Oct 10, 2001
Posts: 214
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.
Ken Reigle
Greenhorn

Joined: Jun 21, 2001
Posts: 5
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.
Amit Saini
Greenhorn

Joined: Oct 17, 2000
Posts: 5
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.
Prateek Parmar
Greenhorn

Joined: Oct 25, 2009
Posts: 1


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.
patrick kunert
Greenhorn

Joined: Dec 07, 2009
Posts: 6
...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)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Sockets, Multiple Clients, and i/o.....mind blowing!!!