Thanks for the reply.
That sounds like a reasonable approach for the release. I will try creating a special factory sometime next week.
In message <p05210200ba5e86b720c2@[192.168.1.50]>, =?iso-8859-1?Q?J=F8rgen?= =?
iso-8859-1?Q?_?= =?iso-8859-1?Q?N=F8rgaard?= writes:
On Solaris however all connections using commons-net timeout after around 4 mins.The only way I see to do something on Solaris is to use jdk1.4.x which has a more elaborate api for Sockets. The program "sock" illustrates this.Right, so what you're saying is that you want to shorten how long it takes for a connect fail if a connection hasn't been established. Yes, prior to the J2SE 1.4, there was no way to do this. With J2SE 1.4 you can either use the connect(SocketAddress, int timeout) method the way you did in sock.java or use the java.nio package to do a non-blocking connect and use select to implement a timeout, the way you would in POSIX/C. For your purposes, you have a couple of options. However, the easiest thing to do, which will require you to make absolutely no changes to the commons-net source code, is to subclass DefaultSocketFactory and reimplement the createSocket() methods so that they create an unconnected socket and then use Socket.connect(SocketAddress, int timeout) to establish a connection. You can add a timeout to be used by the SocketFactory (setter and getter and constructor argument) when creating a connected socket. Then just create an instance of the SocketFactory and use SocketClient.setSocketFactory(SocketFactory) to set the factory used by your TelnetClient instance. For our purposes, we have to put out a first formal release before making changes of this sort. For one thing, we have to agree on a backward compatibility strategy. My suggestion is that the first release be made, which given the current code should be compatible with JDK 1.1 through 1.3. After this, I suggest we abandon compatibility with prior versions of Java and leverage J2SE 1.4 features as appropriate. For example, there is no reason for the telnet stuff to use threads now that we have non-blocking I/O. Changing from a thread-based implementation to a select-based loop will eliminate problems on some platforms, use less resources, be more efficient, etc. Also, J2SE 1.4 finally added SocketFactory and ServerSocketFactory classes in javax.net, possibly eliminating the need for org.apache.commons.net.SocketFactory. The javax.net classes are almost identical to ours and I wonder if the creators of javax.net read an article I wrote years ago enumerating many of the flaws in java.net or they just finally realized what should have been obvious to anyone. Anyway, ours has the advantage of being an interface, but the disadvantage of not being refactored into two interfaces. I'm hijacking the thread, so I'll delay further discussion until after our first release. daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
/jørgen nørgaard ... For privacy ...
e-mail: [EMAIL PROTECTED] | Phone: +45 2627 3769
http://anneli.dk/~jnp/ ... PGP! ...
|\ _,,,---,,_
/,`.-'`' -. ;-;;,_ |,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
