 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / August 2004a problem with Socket
Hi, I create a ServerSocket and then get call accept(). Since no clients are there, the server waits. From another thread I call ServerSocket.close(). After that, I create a new ServerSocket and call accept() again on the same port, but it throws an IOException. What does it mean? Thank you > Hi, I create a ServerSocket and then get call accept(). Since no clients > are there, the server waits. From another thread I call > ServerSocket.close(). After that, I create a new ServerSocket and call > accept() again on the same port, but it throws an IOException. What does > it mean? It sounds as if it might be the restriction most OSes have on the reuse of a socket within a certain time-frame. The restriction is there so that any old packets that were sent to the old socket, but are still in transit somewhere "out there" on the Internet, will die rather than be delivered to the new socket. Off-hand, I can't remember what the timeout is, 2 minutes ? 3 ? 5 ? -- something like that. You can override the restriction by setting the appropriate socket option, see the JavaDoc for ServerSocket.setReuseAddress(). -- chris > It sounds as if it might be the restriction most OSes have on the reuse of a > socket within a certain time-frame. [quoted text clipped - 8 lines] > > -- chris Thank you for replying, but after tried it, it seems not to be this error. In the docs I read that setReuseAddress() works with bind(), while I use connect(). Is the same things? > Thank you for replying, but after tried it, it seems not to be this error. > In the docs I read that setReuseAddress() works with bind(), while I use > connect(). Is the same things? You are using connect() on a /server/ socket ? It's several years since I last did any socket programming (in any language) but that doesn't sound right to me. I'd have expected you to be creating the socket then looping with accept() waiting for inbound connection ? (I seem to remember that you /can/ connect() directly with a server socket, but I can't remember any reason why one might commonly need to -- perhaps it's just my aging memory at fault). Anyway, I believe that bind() happens implicitly if you don't call it. So you should be able to use setReuseAddress() even if you are not explicitly bind()-ing. -- chris Yeah, I explained bad... I use accept() for the server and connect() for the client. Now, the second time I try to connect I get an exception, even setting the setReuseAddress()... Another question... How to make a non-blocking connection? I call the method InputStreamReader.ready() before calling read(), but it always returns false. I'd prefer not to use a differen thread, if I can... Thank you again... > Yeah, I explained bad... I use accept() for the server and connect() > for the client. Now, the second time I try to connect I get an > exception, even setting the setReuseAddress()... First, why don't you post your client and server code. Second, state clearly which process is getting the exception (the client or the server), and at exactly what point in the code. What is the other process doing when the exception occurs? Does the client close his original socket? Does the client specify a *local* port or local address for either of the connecting sockets? > Another question... How to make a non-blocking connection? I call > the method InputStreamReader.ready() before calling read(), but it > always returns false. I'd prefer not to use a differen thread, if I > can... Thank you again... Use a java.nio.Selector to handle multiple connections from a single thread. On the other hand, if there will only be a single connection, there is no reason to not let your process block while waiting for input from the peer. If you use ready() or available() in a loop that just reads from a single Reader or InputStream, you are simply wasting CPU in order to avoid an imagined problem. /gordon  Signature[ do not email me copies of your followups ] g o r d o n + n e w s @ b a l d e r 1 3 . s e (alessandro) >> Yeah, I explained bad... > > First, why don't you post your client and server code... <http://www.physci.org/codes/sscce.jsp> SignatureAndrew Thompson http://www.PhySci.org/ Open-source software suite http://www.PhySci.org/codes/ Web & IT Help http://www.1point1C.org/ Science & Technology Ok, now the problem with the connection is solved: when the server was listening and I closed the connection, I didn't call ServerSocket.close(), so the next time the system wouln't let me create the same ServerSocket. > Use a java.nio.Selector to handle multiple connections from a single > thread. I don't know what JVM version is installed on the target machine. It could be not the 1.4. Other than that, is not this the very problem. > On the other hand, if there will only be a single connection, there is > no reason to not let your process block while waiting for input from > the peer. There is a GUI. The user should be able to interact with it. >If you use ready() or available() in a loop that just reads > from a single Reader or InputStream, you are simply wasting CPU in > order to avoid an imagined problem. This would not be a problem. The read() method would be called from a timer 10 times per second or so. The problem is that (following the documentation), available() always returns 0 on some systems, and should not be used in these manners. Then I tried ready(), but returns false. I would like not to use a separate thread for the network class, since that would mean adding a lot of extra code. This app will be used just one time (university project) from my professor... Thank you for the help. Alessandro > There is a GUI. The user should be able to interact with it. and: > I would like not to use a separate > thread for the network class, since that would mean adding a lot of extra > code. This app will be used just one time (university project) from my > professor... If you have a GUI and networking at the same time then you need theads too. Period. If your prof has set an assignment that requires both then you can rely on it that he or she is expecting you to recognise the need for threads and do the necessary programming. It actually doesn't take much effort to do the threading, and is certainly easier than any /working/ non-threaded implementation would be (if one were even possible -- and I'm not sure it is). -- chris > If you have a GUI and networking at the same time then you need theads too. > Period. [quoted text clipped - 5 lines] > It actually doesn't take much effort to do the threading, and is certainly > easier than any /working/ non-threaded implementation would be (if one were e it is). > -- chris Ok, then I'll go with threads... Thank you for the help... Regards Alessandro >>There is a GUI. The user should be able to interact with it. > [quoted text clipped - 7 lines] > If you have a GUI and networking at the same time then you need theads too. > Period. (unlurking to interject a question from an old Fortran programmer trying to learn Java) Is this because the handling of network interactions and the handling of user interactions in the gui are both event-driven processing? Just curious at this point (though I am taking a Java intro class starting in a few weeks)... Jim C > If your prof has set an assignment that requires both then you can rely on it > that he or she is expecting you to recognise the need for threads and do the [quoted text clipped - 5 lines] > > -- chris > > If you have a GUI and networking at the same time then you need theads > > too. Period. [quoted text clipped - 3 lines] > the handling of user interactions in the gui are both event-driven > processing? Essentially, yes, though not in detail. The networking APIs are not event-driven, but the GUI is run by one dedicated thread which calls your code in an event-driven manner. Because it's all handled by one thread (rather than, for instance, one thread per window) you must not issue blocking calls from one of your event handlers. That rules out using the blocking networking APIs. OTOH, you don't naturally have a guarantees about /when/ the thread will invoke your callbacks (it may not do so at all if the user has gone for lunch), so you can't use polling APIs for the network either since you may not poll often enough. It is probably possible to hack something together that would arrange for the GUI thread to call your code every -- say -- 10th of a second during idle time, without using threads. But that would be convoluted and inefficient compared to the natural solution of just using threads. (Incidentally, this is a restriction of the Java APIs. It's a (IMO) pretty good design choice, but is not the only workable option; Windows for instance will allow you to code GUI and non-blocking Sockets driven off the same event loop.) > Just curious at this point (though I am taking a Java intro > class starting in a few weeks)... Good luck, I hope you enjoy it. -- chris >>>If you have a GUI and networking at the same time then you need theads >>>too. Period. [quoted text clipped - 31 lines] > > -- chris Thanks for the explanation, Chris. It will definitely be a change from the straight procedural codes I've worked on for the last (mumble) years, but thanks to the beginning of my career dealing with multi-threaded assembly code running real-time comm operations on a mainframe I hope to be able to wrap my brain around Java and the whole objects thing eventually... :-) Our long-term goal is to migrate apps from workstation-based Fortran/C directly accessing the database (Ingres) to platform-independent apps that use JDBC to interact with the DB. Gotta learn a new language to achieve *that* goal! Jim Looks like you are looking to build an tcp server in java.. check this out www.quickserver.org i use it and it rocks.. > Ok, now the problem with the connection is solved: when the server was > listening and I closed the connection, I didn't call ServerSocket.close(), [quoted text clipped - 28 lines] > > Alessandro Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.