its very dengerus
It's spelled "dangerous", and no… It's not necessarily dangerous. There are a number of factors to take into account when assessing risk factors, the biggest of which is the person's viral load. It is scientifically proven that an undetectable viral load alone is safer than a condom, so I'd beg to differ on that point.
@daydrm: Define responsible behaviour? It's scientifically proven that it is safer to bareback with an undetectable partner than it is to have sex with a condom with a person with a high viral load. So…. how may I ask is having unprotected sex with a person who is undetectable "irresponsible"?
I agree…. Stigma isn't as bad as it used to be, even back as far as 2009 when I was diagnosed. That being said though, there's still a long way that we need to come with stigma unfortunately. :cry2:
While this a very odd way of thinking I do believe there is at least a one out of four chance that gay/bi people have HIV and don't know it.
According to Statistics Canada, approximately 65% of persons infected with HIV do not know it until the positive test result comes back. Of that 65%, 43% of those do not show symptoms of any sort.
Exactly as I suspected…. When the route goes through Switzerland to China, then it bounces through the United States, the connection works just fine...
When the route tries to run through the 3bb platform most of the way, it seems it chokes.... This confirms what I suspected, and actually makes me think that the technician doesn't know what they're doing :lolp:
What I find interesting is this part of the one traceroute where it does not work
8 34 ms 37 ms 33 ms mx-ll-110.164.1-6.static.3bb.co.th [110.164.1.6]
9 226 ms 226 ms 226 ms 192.168.255.250
The interesting part is to see if the internal LAN IP that you're reaching where the ping suddenly spikes is on 3bb's end, or if this is an obscure private link between 3bb and nForce that isn't working correctly. Based on the sudden spike in the ping between the two, I'm willing to put money down that says that this is where the connection drops when it fails. If this internal hop is between 3bb and nForce, this may explain why 3bb is saying that the problem is with GT.ru because they're only looking at the packets as they pass through the 3bb network. This definitely does confirm my theory that it's an aggregated network that uses dynamic routing. If they were smart, what they would do is to pull the dynamic route that runs primarily through their platform, since there's obviously a disconnect somewhere between 3bb and nForce when they route traffic this way. 
So… It's possible that the packet leaves the 3bb network successfully, but chokes between 3bb and nForce, in which case it would only make sense that 3bb is scratching their heads, because they're completely overlooking a major routing issue. The internal 192.168.x.x IP address is also of some concern as generally speaking, you're not supposed to have private network addresses along a route, unless the route is accessible through your network directly. This is to ensure that you're able to successfully ping and route through that gateway, which leads me to believe that the problem is in fact within 3bb's network, namely in one of their exit nodes that passes traffic out to one of their internet exchanges. If this is the case, then the problem is on 3bb's end because it's one of their own internal exit nodes that is failing. This will no doubt create major routing issues for more than just GT.ru. Come to think of it, it's likely that this internal link is indeed a 3bb link, in which case they're just full of shit and don't want to fix their own platform. I know that latency will vary slightly from one hop to the next, but with a difference in latency like that (spiking from 34 to 226 ms) is generally an indication that either there is a hardware issue with the link, or that said link may be over-saturated with network traffic, in which case, their load balancing is not properly configured.
I'd be inclined to start asking questions about that route myself as the sudden spike in latency is definitely something that shouldn't be happening. Since the problem seems to be with one of the dynamic routes that they're taking, this would explain why a VPN makes it work, as this forces traffic to take a different route, thus bypassing the particular gateway (or node) in the 3bb network that links into the internet exchange to hop over from Thailand to the Netherlands. While the traceroute may be able to make its way through to nForce, I kind of wonder if the larger packets such as would be used for HTTP traffic are too large to be able to pass through, due to whatever is causing the latency to spike at that point in the connection. The other thing that I find interesting is that on two separate routes, there's a ping timeout when the connection routes through China, which leads me to believe that there may be an intermittent problem on that end of the platform when it runs through the Nine network. One thing that I can say for sure though is that there is definitely dynamic routing in place here, which explains why it works sometimes with 3bb, but not others, depending on whether or not it takes the route through the faulty link at the end of 3bb's platform.
Speaking as someone with over 20 years of networking experience, to me, this sounds like a routing problem on 3bb's end actually. If they're using an aggregated network, it's likely that they are using dynamic routing which would mean that depending on the time of day and network loads, they attempt to route the connection through a path that is problematic only some of the time, as is the nature of dynamic routing, which is more common to aggregated networks. I would be curious to see the traceroute as far as it will go (to Hyperfilter IIRC) on a day when it is working and a day when it is not to see the difference in the route that it tries to take. Chances are that it may not be directly on 3bb's end, but rather, something to do with blockades being put in place by one of their third party upstream vendors that provides the actual route through the internet. If this is the case, this would explain why 3bb is scratching their heads trying to figure it out, as the problem would be with the routing through only some of the network paths that they use. The sad part about dynamic routing is that depending on a number of factors, the route will change from one time of the day to the next. I suspect that the problem very well may be that they are trying to route though another country at times, which may run into blockades placed by foreign government.
The other possibility (although unlikely) is that the problem lies within the DNS servers, which do not actively respond properly as they should, although from the sounds of it, this is far less likely. Part of why I suspect that it may be the routing is based on issues that I have seen pop up with my ISP from time to time. For example, there was recently a problem with one of the routes that my ISP (TekSavvy) was using to get to YouTube. The connection would pass successfully from my modem, through their gateway, through the Toronto Internet Exchange (Packetflow I believe they refer to it as), then would bounce through Hurricane Electric's network grid. The problem came in however that when trying to send the traffic through one particular route through HE (Detroit I believe it was), the packet would make it into the first system, but then would frequently drop between the first hop in HE's system in Detroit and one of the two following relays in that route. Once TekSavvy changed the route to run through Chicago instead, the problem cleared up. The interesting part is that this problem was not limited only to YouTube, but also to other streaming sites, some of which were located in Canada. So… Even though the connection was going from Canada to Canada, at some point in the middle of the route, the connection takes a few bounces through the United States... So.... If the same kind of thing is happening with 3bb, it is possible that the problem may be with the dynamic routing trying to route requests at times through a country which has a blockade on this type of internet traffic.
It's a very high-tech explanation, but I'm almost certain that this will be the key to what the so-called "professionals" are overlooking. That is of course, assuming that they are actually being retarded and overlooking the possibility of routing through a foreign territory in some of their dynamic routes, rather than just not bothering to mention it or check for it because it's a "gay" thing, so they cannot be bothered. I don't know how vast homophobia is in that part of the world, so it's hard to say whether they're overlooking it, or they're just assuming it's not on their end because the connection leaves their network, so they cannot be bothered to look into it in more detail. Nevertheless, the traceroutes on a day when it works and on a day when it doesn't work compared to one another will surely tell whether or not this is the case. I would strongly suspect that their "technicians" are defined as the "barely trained" technicians as referred to in this video are just blindly pointing the finger at GT.ru for the problem because they're not looking past their network. They're likely only looking at the traffic as it passes through the part of the network that is their own domain, ignoring the fact that problems may arise in the routing past their network, but before the destination.
Perhaps this may provide the answer to your problem? If the routing is the case, this also explains why the connection works just fine through a VPN, as a VPN will force all of your traffic to be routed through the VPN tunnel to get out to the internet, thereby forcing it to take a route other than the one allocated by your ISP by bouncing the traffic off of the VPN instead of taking your ISP's default route.
I'm not sure how that would have happened as mods who do picture approval are supposed to check to see if the pictures are relevant, but I can say this…
If you see this kind of thing on your torrents, please hit the report button to flag it for the pictures so that mods can correct this for you. I know this isn't the ideal solution for you, but it is an option that we can use with the system as we have it currently. I do understand your frustrations completely. I'm just not sure that the powers that be would be too willing to jump straight to that (just to be honest up front).
Also… Allow me to quote the FAQ bot from the chat...
<faqbot>New to the site? Here are a few helpful threads: https://forum.gaytorrent.ru/index.php?topic=13101.0 https://forum.gaytorrent.ru/index.php?topic=707.0</faqbot>
Google DNS: 8.8.8.8 / 8.8.4.4
Open DNS: 208.67.222.222 / 208.67.220.220
Dyn DNS: 216.146.35.35 / 216.146.36.36
DNS.Watch: 84.200.69.80 / 84.200.70.40
Commando Secure DNS: 8.26.56.26 / 8.20.247.20
I hope this list is helpful… Also... For some users, I may be able to offer DNS services with the current system that I run and host. If you're interested, please let me know.
Also... I forgot to mention... There are two other options that you can use to get around that.
Option #1 (recommended): Use of a VPN server. This will tunnel absolutely all of your internet traffic, including DNS requests and such through a secure tunnel to a remote location. This also masks your real IP address as well as the nature of what you are doing.
Option #2: Use of a proxy server
You have to have open wounds in your mouth, AND the person who you are going down on has to have a substantial viral load. As a general rule, oral sex is considered to be low risk.
This is correct… There is not one documented case of transmission from an undetectable partner. This is not to say that it's impossible as there is no evidence that it is impossible, however despite several recent studies done to attempt to quantify the risks among MSM[nb]Men who Sleep with Men[/nb], there is no evidence that conclusively proves that it is either, despite efforts to acquire such evidence.
So… With that being said, it is starting to become generally accepted to say that sex with someone who is undetectable is safe. Statistically, it's actually safer than having sex with a condom with a partner with a high viral load. Just sayin'... Let the facts speak for themselves and draw your own conclusion from what evidence does exist.
This largely depends on what medication regime that you're put onto, as well as what kind of pharmacy that you go to.
My original medications cost $1533.53/mo at a cheaper pharmacy, whereas at the big name pharmacies, they would easily run well over $3500. My current supply costs me just under $1400/mo. Thankfully, one thing I love about the Canadian healthcare system is that they pickup the bill on these medications as they're deemed to be a necessity of life.
The most common symptoms are often mistaken for influenza (better known as the flu)… They can include body fatigue, body aches, upset stomach, nausea, fever, night sweats, and a sudden loss of weight just to name a few. This is the sad and scary reality. The only "symptoms" that you can sometimes have are pretty generic and are often associated with the flu.
This largely depends on where you live. I don't know about in the United States, but I know within Canada, you can usually get the testing done anonymously through your public health unit. If not, I would imagine you can at least get this information from your local public health unit.
Just to point something out… There has yet to be so much as one documented case of HIV transmission where the only sexual contact was oral.... Just sayin'.... This doesn't mean it's impossible for transmission to occur from oral sex, however it is very suggestive that the risk isn't very significant to begin with from oral sex.
I'm not sure about the "Warned" status. I will have to look into that for you. I can say however that I had nothing to do with that part of it.
The first part of your problem may be the fact that you are using BitComet. I would not recommend BitComet for a torrent client, or even a multi-purpose downloader for that matter. I´ve had nothing but bad experiences and frustrations when trying to use it.
Just out of curiosity, are you downloading the entire contents of the torrent, or are you downloading 100% of ALL the files. If you do not download 100% of ALL the files, you may experience issues with the tracker showing that you´re leeching the torrent, even though your torrent client will show that it is ¨seeding¨ the torrent.
[box title=OffTopic]I´ve seen just about enough of this crap between the two of you Ellis and cannonmc…. Every post that I see, cannonmc makes a comment for whatever the reason, which doesn´t come across as offensive, derogatory, or otherwise out of turn, and in return you (Ellis) seem to have this fixation with launching an attack for simply participating in the forum. Why is this Ellis? Why is it that you seem to feel the incessant need to attack other users? I may remind you that we have rules about this kind of thing, so it must stop NOW![/box]
Is it possible that you may have attempted an upload previously that you abandoned before trying that upload? I know sometimes when you've started a manual upload, it tends to keep pictures you have started to upload, making them appear the next time you attempt a manual upload. I´m not exactly sure as to why this is, I just know I´ve come across it a few times now in my days.
It is important that your torrent client is 'connectible', if not, downloading peers will download from other peers who's torrent client is connectible.
Speaking of which… Is there some reason why our system´s connectable status detection seems to be broken? It shows EVERYONE as being connectable, which I know is just NOT the case as there are a lot of users who do not know about port forwarding.