Hello I own the most recent version of LW pro and have been unable to connect. It stays at the connecting (1 green bar) for as long as LW is running. The bug report says false but I do not own any firewall whatsoever. I've tryed almost every single thing anyone's put forward. I have windows xp and cable internet. I was able to connect 1 night since i've owned LW and stayed connected untill I shut down. The next day boom, No connect. I'm willing to do anything to get my $18 worth. Thanks

Uh uh, tried that...no luck (see my posts "Limewire connecting..."

I have done absolutely everything that was suggested, short of hiring a computer expert! I get bursts of turbocharge for an hour and then try to get connected for two days! I am on XP, and I am ready to go back to reading books. I am tired of staring at the "connecting" and the red levels.

I.M. Givingup can you give us a total desciption of your set up: 1. OS version, 2. What firewalls you have, 3. ram, 4. HDD space available, 5. Connection type, 6. Modem & router brand name & model numbers, 7. Where are you trying to connect from (home, school, work, etc.)?
These details are vital if you want us to find out what your connection problem is.

Make sure your Java is up to date: Java 1.5 (take the JRE)

I have seen this happen, and I have one possible reason about this behavior (connecting for some time than impossible to connect) if:
- this does not come from your ISP: your connection is still working
- you can still browse the web and send emails or discuss on IRC
- all connection attempts fail
- you use an external DSL modem with connection sharing (embedding a Ethernet adapter or hub, or a WiFi adapter)
or a router with NAT, or connect via a PC acting as a connection sharing gateway
- you are running Windows XP SP2


Windows XP SP2 also monitors the number of target (non local) IP addresses that can be reached by TCP connections: this is monitored by the OS's IP driver, within its internal routing device as a feature of its builtin firewall. This mostly concerns users of Windows XP Home and Pro editions, but not the Server editions... I don't know if this is a default tuning that can be changed. But the only solution is to terminate the process (exit LimeWire completely, including its Java VM and the taskbar icon), wait for about one minute and restart.

Windows XP SP2 has put severe limitations on the number of DNS resolution requests that can be resolved by a client process (this is used as a tool to limit the broad connectivity of a possibly installed virus trying to send spam at large speed to lots of destination hosts). The impact is that the number of DNS resolutions per timeframe is limited, and above this limit, these requests will fail, and the limit will be automatically lowered. This limit cannot be reached when running LimeWire at startup, but cn be reached after about 2 hours of successfull connection, because the connected hosts that stay online for more than 1 minute will have their IP resolved by LimeWire into hostnames. However, if your servent has run successfully for more than 1 hour, it may become a Ultrapeer candidate, and then then will start accepting remote leaf connections. The problem is that the rate of incomming connection attempts cannot be controled, and remote leaf nodes will frequently connect and disconnect.

In the past, all connected hosts were resolved to hostnames, but now this resolution will not happen before at least 1 minute of successfull connection. Given that a typical Ultrapeer will accept about 30 leaf nodes, this has the effect of putting a maximum to the number of DNS resolutions performed by LimeWire.
LimeWire has also been modified to not resolve IP to hostnames if the Connection pane is not visible.

Another problem is that Java, used in LimeWire, incorrectly implements the DNS specification, caching *for ever* the DNS results (Sun says this is part of an anti-spoofing security feature, but this is not satisfactory, and contradicts the RFCs. The impact is that the builtin Java DNS client will store obsolete records, and this includes many records related to IP or hostnames that are dynamically assigned to termporarily connected hosts, such as most connections provided by ISPs and used by home users.

Tip: LimeWire has recently been modified to not use the Java builtin DNS client, which also uses internally the local DN client provided by the OS, and it now includes a separate implementation of a conforming caching DNS client (where records will expire according to DNS protocol requirements). One problem is that Windows XP SP2 will not let LimeWire create itself connections to external DNS servers, unless the builtin XP firewall is configured to let LimeWire perform such Internet accesses (the DNS is a critical shared resource of the Internet).

But your ISP may also have set severe limitations to the number of DNS requests that can be satisfied by its customers. This is because the DNS server that your ISP connection uses is typically shared by all customers of that ISP, and the ISP's DNS server needs to be able to serve all customers equally and is necessarily limited. Some ISPs are also using this feature to detect automatically the customers that are infected by DDoS-like worms, or running P2P clients: when this limit is reached, the customer connection is reconfigured to limit more severely the number of DNS requests that can be satisifed. This has the benefit that the ISP can effectively reduce the success of DDoS worms or spamwares, and this also saves lots of bandwidth used by these worms. But some ISPs are logging those customers and will list them for analysis by external tools (including providing the list to third parties that have contracted with the ISP to monitor the legality of files shared on P2P networks). These logs can also be kept for legal purpose, but this is not possible legally in all countries. Apparently, such logging is now required in US and in all 25 countries in the E.U. that have applied the European directives.

If this is the case for you, there are two solutions:

(1) install a local caching DNS server with large enough caches, then connect this local DNS server to the ISP's server, configuring it so that it will make sure not to make too frequent resolution requests to the ISP, then configure your host to use this local DNS server instead. This is complicate for most users.

(2) close the "Connections" pane in LimeWire: LimeWire will not attempt to resolve all remote IP addresses to hostnames. But LimeWire will still need to connect sometimes to Gwebcaches, using the URLs that need to be resolved with DNS: this event will occur much more rarely now than with past versions, since now LimeWire prefers a much better alternative with UDP host caches. (If your servent was connected successfully for more than 1 hour and has become an Ultrapeer, LimeWire will not need to perform any access to GWebcaches, as its local pool of known remote hosts will be constantly filled with fresh addresses, and should not be exhausted.)

But the problem may be elsewhere: if you have a local firewall software (not the builtin Windows XP firewall), this firewall may be configured to resolve ALL incoming TCP connections for logging purpose. Consider changing the setting of this local firewall so that it will not perform this costly resolution. Such function is normally performed in offline mode when parsing webserver logs, or should be enabled ONLY if you have a *true* local DNS server with enough caching (the builtin DNS client in Windows XP has a cache but it is too much limited to work correctly for applications that will connect with lots of distinct Internet hosts).

Same thing if you have an external router: some routers will also attempt to perform DNS resolution for ANY application running on LAN, and will immediately try to cache locally the result of this resolution. This occurs if the builtin DNS proxy is enabled in the router, and your hosts on the LAN are configured to use the DNS server address of the router. The problem is that most builtin DNS procies in hardware routers have too much limited memory to cache enough DNS records, and so these records must be discarded with a LRU strategy, long before the recommanded caching time indicated by the remote DN server (which should be about 24 hours for permanent web servers, or about 1 hour for DNS resolutions of ISP-provided hosts with dynamic IP).

The solution is then to disable this DNS proxy in your router, and configure the router's builtin DHCP server so that it will not distribute its own address for the DNS, but the address of your ISP's DNS server. This hardware router's builtin DNS proxy may also be configured to work in non caching mode (if this setting is possible), so that your hosts on the LAN will continue to use it in "plug'n play" mode using the router's address provided by its builtin DHCP server.

If your router does not have DHCP, or if you can't change its settings, you'll need to manually configure your local host to not use the DNS server address provided by DHCP, but to configure manually your host with the IP address of your ISP's DNS server(s). This should also sove the problem caused by a local firewall software that monitors and resolveds all the Internet connections performed by your local applications, to detect and block known malicious hosts in their "blacklist".

But the most tricky cases come if you are running your servent on a host connected via a shared enterprise or university network: whatever you can do in your host, they control and monitor your activity, and provide you a limited access to the Internet, and should have given to you a usage policy that you must respect. LimeWire cannot do anything for these cases if your connection fails because of this external monitoring, for networks accesses that you don't own yourself... Some solutions may be possible sometimes, for example by using some other publicly accessible DNS servers available on the Internet (but you should care about the fact that those external DNS servers may not be trustful, and may redirect your internet accesses to advertizers, or modified versions of wellknown search engines like Google...). I won't recommand using such untrustable third party services, even if they are, illegitimately, called "internet accelerators"...

Note that some ISPs propose you such "internet accelerators" as a builtin feature: they will act as "transparent" proxies and will deliver you cached webpages (for faster accesses) with compressed data (useful for slow modem connections):
- AOL modem accesses for example causes such troubles, and the best you can do if you use P2P applications is to avoid AOL and seek for another ISP.
- Wanadoo's optional (subscribed and payed option) "internet accelerator" feature causes such troubles. The utility of such subscription is very questionable, given the interoperability problems it can cause, even if it successfully accelerate your experience for classical web browsing.

Finally, there's a problem that is specific to Windows XP SP2: it sometimes does not detect that the Internet connection has been shutdown and restarted on your external router, and its TCP/IP internal stack continues to use obsolete information, or sometimes Windows XP continues to use obsolete DHCP leases that have expired in the DHCP server of your router. The symptoms is that you can't perform any web activity (getting emails, browsing the web, all fails with "host not found" errors).

Sometimes this can be solved by disabling the NIC interface and reenabling it. But this sometimes fails too: the dialog box that appears when "repairing" the connection never terminates, and can't be closed even if you press the "Cancel" button (using the "Repair connection" fails for obscure reasons, as the local DHCP client in Windows XP is blocked in an internal thread waiting for some unknown event that will never occur). Even if you unplug the Ethernet cable, Windows XP will not detect this event, and the connection will remain "active" and the network icon in the status bar will not show the red-cross.

The only solution is to reboot; this looks like a bug in Windows XP SP2's builtin firewall, caused by mutual dependencies of various internal network services, causing some deadlocks when one of these service should be unlocked to fail immediately... This bug may also come from your antivirus tool that does not monitor some Windows XP events informing it that the IP connection state was reset: check that your antivirus tool is updated to work correctly with Windows XP SP2 builtin firewall (this builtin firewall informs applications via some intenal hooks that your antivirus still does not implement, or via new UPnP or SNMP events that your antivirus still does not implement, or that can only be caught if the antivirus is configured and updated with the privileges of a local administrator account).

One solution, if you already have a third-party firewall solution, is to disable the Windows XP builtin firewall, and its related features (the new "Security Center" that displays a yellow or red shild icon, and that performs automatic Windows Updates, when you are online). Get sure then to perform Windows Updates regularly (most of them are published on Tuesday by Microsoft, so if you check them once a week on Wednesday, you should be OK with security patches).

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

verdyp does that mean it's not wise to recommend Sun Java 1.5? 1.5 JRE seems to work better for some whereas 1.4.2 works better for others. Or is 1.5 not recommended for XP SP2 users?

When my modem stops communicating with my computer & requires a reboot of possibly both devices, do you know what causes that? Is it overloading of the processor/ram (macosx)?

Java 1.5 is still not a stable release, but it definitely improves the performance, reduces the memory footprint, and its networking support is much better. In addition, its computing speed is much faster, its multithreading support is smoother, and internally it uses much less locking operations on objects (notably in the processing of Strings). Finally, its garbage collector is faster, and better tuned, meaning that it uses internal memory in a more efficient way, and includes a memory defragmenter, meaning less swap on disk and better data locality. For performance critical operations, its support of asynchronous I/O, and audio is better tuned; it also includes the support for precompiled and shared classes, which means faster load-and-run, and a responsive application.

I don't think that there are more bugs in Java 1.5 than with Java 1.4.2. In fact, since Java 1.5 has been put into production, many bugs that are found in either platforms are updated in parallel in Java 1.4 and 1.5, because they share lots of common components. So the difference in the two platforms are less important: LimeWire uses the Java 1.4 platform which runs identically in Java 1.5. The difference in Java 1.5 is mainly in the core components that integrate the GUI: Swing and AWT components are based on Java2D, and they are identically on both platforms. But Java2D uses the native graphic APIs for the OS platform, and this includes DirectX (preferably to OpenGL on Windows), Qt and OpenGL on Linux, or MacDraw on MacOS...

Most freezes that users have experimented in the GUI have been solved in Java 1.4.2 face to Java 1.4.1, and retrofitted into Java 1.5 as well, becuase the support for native APIs is shared a lot between Java versions.

Networking components are mostly equivalent between Java versions, and they are mostly portable because they are written in 100% Java code (but note that Java 1.5 includes new StringBuilder objects instead of StringBuffers, which improves the performance in most cases because StringBuilder is not synchronized across threads; the numerous changes in Java 1.5 core classes is in the suppression of most unnecessary synchronization, and the extensive use of shared/reusable buffers to reduce the number of unique allocations and memory copies for temporary objects.

The main difference between Java 1.4 and 1.5 is the support for new language features like Generics (related but not equivalent to C++ templates), which LimeWire does not use, but that the source core classes bundled with Java can use. The binary format of class files is not equivalent, but LimeWire is compiled using Java 1.4 binary formats, without those extensions. There are also improvements in Java 1.5 regarding internationalization, with a more complete support of Unicode 4; this does not affect LimeWire which does not need or use now this.

Other improvements in Java 1.5 is that the customization of fonts is easier, supporting international fonts in a less platform-specific way. So Java 1.5 offers now a transparent support for all languages other than the default platform language. But LimeWire is built to run best in the default platform language, by letting users select these locales, and not necessary the English one.

Personnally, I have never experimented any Java VM crash or freeze since 1.5 is released, but I had a few ones with Java 1.4. Some reasons were caused by Java2D's use of DirectX, whose support in Java 1.5 is much improved, and includes more workaround for compatibility problems (notably with defective display drivers).

However I won't recommand the configuration of Java2D with OpenGL, because too many display drivers have not been so much extensively tested through OpenGL, and some of their interfaces are not multithread safe as they should, or do not work well with parallel applications. Other problems are in native font renderers, which have some known problems, solved in Java 1.5, but with partial workarounds on Java 1.4.

Things like OpenGL screensavers should be disabled in Linux, if you use LimeWire on this platform, and LimeWire will run better if your Java installation includes the support for Qt instead of OpenGL.

In most cases, crash/freeze bugs come from defects in display drivers, that don't implement the OS APIs as documented by the OS vendor, and that incorrectly assume that some events will come in some typical order, generated from the platform's graphical components. As Java bypasses most of these platform components, these events may come into a different order, still valid and possible as documented in the OS APIs, but causing, incorrect displays, hardware crashes, memory corruption, incorrect synchronization in multithreaded applications (like the platform's file explorer, or Java or LimeWire).

When you experiment such problems, get sure that you have the most up-to-date drivers for your display drivers, and that you don't use the "enhanced" but not certified versions of these drivers. Users that have tweaked their installation with such drivers are exposed to risks that such installation has not been eveluated and tested to support correctly all the OS features; Sun or Apple cannot test their Java installation across all hardware driver variants, but they do test them with the most common ones. This is a problem for those that use obsoleted display boards that were built by manufacturers that have stopped supporting them (notably all those many that had a 3Dfx board, which don't have any available upgrade that correct defects to support newer versions of their OSes). Those users are left with unsupported drivers for their new platform.

So a good question for those users is whever they should upgrade their OS, or if they should better buy a new PC or Mac with components made and supported on that platform: adding memory or changing disk will not solve those hardware-related problems, even if it theorically allows installing the new OS. The reality is that what they do is completely untested by all software providers, including Apple and Sun in their distribution of Java.

It is even more difficult to predict, for LimeWire, which networking platform will be used: this is a domain with lots of variants that are hard to reproduce, because there are specificities varying depending on technology (routers, broadband access types, proxies, addessing and naming, network autoconfiguration and discovery...) and that LimeWire does not have tested itself. Additionally, many bugs are produced by third-party networking components (including security tools like firewalls and antivirus), where there's often no definitive standard for interoperability...

The case of NAT routing is certainly one where LimeWire or any P2P application have difficulties to work with, because most Internet components were not designed for P2P. Things are changing, slowly, because P2P technologies are experimenting the same problems needed for other important technologies: grid computing, n-tiered applications, clusters and redundant hardwares, IPv6, mobile/roaming networks... With the new (basic) support for UPnP in LimeWire, we can adapt to those situations, but this will come progressively, because of the lack of a significant deployed platform to reproduce and experiment the problems and implement possible solutions.

So my response will be that Java 1.5 is recommanded now for most users, but if this fails for some of you, get back to Java 1.4 and check your hardware and OS components. LimeWire cannot be made to guarantee that it will work on all platform configurations and for all users, but LimeWire can be made to work with new standards. Java 1.5 is one of these new standards that is working so well for many.

__________________
LimeWire is international. Help translate LimeWire to your own language.
Visit: http://www.limewire.org/translate.shtml

i still have some connection problems, it says that its connecting..but it never connects. Can anyone please tell me what the problem is? thanks

Hi, iv just got limewire and the first time everything was fine , then after switching off my computer and coming back, it just stays on the connecting sign showing red bars,
im on windows xp
and have panda protection,
iv done everything said in the help guide to get past the xp and panda firewall. but it seems od that it would let me use it the first time and not the next, maybe its some thing simple, please help as iv been here flipin hours.

thanx starv.

I'm having the same problem here. The first couple days it worked great but now i can't get a connection. It's always says connecting- waiting for a stable connection. Forgive me i'm new to all this. I have dial up. No firewalls. If anyone can help i would appreciate it.