On Mon, Jul 13, 2009 at 02:09:26PM -0700, Alan Steinberg wrote: > Good stuff. I did reboot before I saw your email, and on 117 I saw that > it would take a long pause, then continue, pause again, and continue, > but it did complete. After rebooting on 118 I did set PKG_CLIENT_TIMEOUT > to 300, and it also worked. > > Note that my network connection is through punchin onto SWAN. Since the > behavior did change between bld 117 and 118, is there a bug that should > be opened, or something documented for setting PKG_CLIENT_TIMEOUT with > this build, or am I just in a unique situation?
No, your situation isn't unique. I just filed: 10010 reconfigure transport timeouts There a number of different issues here. First, I confused the existing definitons of our environment variables when I re-wrote the transport code. Second, libcurl doesn't use the same notion of timeout as Python does. In Python's socketmodule, the timeout is the amount of time poll/select will wait for a packet before giving up on the connection. In libcurl, it's the total amount of time for the transaction. Since the packaging client is run in a diverse set of network environments, it doesn't really make sense to put an overall timeout on the transacation, since they vary in size -- picking one size that will fit all situations is likely to be impossible. I think it makes more sense to put a limit on the amount of time the client will try to use before it gives up connecting, as well as a limit on the speed of the connection. Libcurl can be configured to abort connections that are too slow, which seems like an acceptable approach instead of limiting the overall transport time. -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
