On wireless connection, text sometimes repeats twice or three times?

Hello, a quick question to ask if anyone has experienced this before. I have a friend on a wireless connection (protocol 802.11g) and the problem is that when my friend talks on SL, text is sometimes repeated twice or even three times for no apparent reason. It's very frustrating. For example, conversation may go vaguely like this:


Friendly Friendlyson: hello
You: YOOO
Friendly Friendlyson: whats up
Friendly Friendlyson: whats up
You: Hmmm your text is repeating
Friendly Friendlyson: is it
Friendly Friendlyson: is it
Friendly Friendlyson: is it
You: Yeah
Friendly Friendlyson: damn
You: only some lines seem to though?
Friendly Friendlyson: really? hm
Friendly Friendlyson: really? hm


We've established this:

-everything else in SL, performance-wise, seems fine. This would include lack of packet loss.
-chat is visibly repeated to the other party in open chat but NOT in IM
-text repeats inconsistently in SL, as demonstrated above
-product being used is a Versalink Gateway as per:
http://www.westell.com/content/products/pdf/versalink.pdf

Are there any known issues involving SL and this? I've searched around and nothing's come up thus far. I've read a few reports of Linksys routers (wired) having problems but I'd like to know if anyone's personally experienced this same thing, and if they solved if -- and if so, how.

Thank you graciously.

SL uses UDP rather than TCP for all data. Yes, even important stuff like chat. Concequently, on a high-latency or high-packet loss connection, messages can be dropped, received out of order, or received multiple times. I seem to remember some discussion about correcting this issue on the client, but evidently it hasn't happened. If it's any consolation, I haven't seen it lately.

The only real advice is that using a wired connection will reduce this. Other than that, no, there's not a whole lot you can do, other than try and make sure you're not using the same channel as your next door neighbours. Depending on OS, use NetStumbler or MacStumbler to figure out if there are any interfering networks nearby. That's something of a long shot, though.

I used to have the same problem on my network (which has a hub that supports both wired and wireless LAN connections). I fixed it by ugrading the firmware on the router.

Mine's a Linksys router, so your mileage may vary, but I would suggest that your friend make sure that the router is all up to snuff.

- Ace

While that's true at the UDP level, every UDP-based system outside of Networking 101 class (and even there) puts its own reliability layer in between the chaos of the network and the sanity of the application.

Chat messages will be sequence-tagged within their data frame to make up for the lack of TCP-type sequence numbers in UDP, so there is no excuse for repeated messages in a professional design. My guess is that the sequence checking is broken in the reliability layer, that's all. Report it as a bug.

i think its basically the client not recieving an ack/confirm packet from the server after sending the text you type, so it sends it again, and again, until it gets one.. usually happens with >800ms pings or >10% packetloss

satelite connections specifically are vulnerable to this as they innately have extremely bad ping times

Sure. But the client is only meant to accept one of them, the first one it receives with a correct checksum. That's why you tag the data with a sequence number, so that you don't accept repeats.

what i believe is happening is the client isn't getting *ANY* ack from the server across bad connections (within its timeout threshold) so it sends 'hi guys' and waits abit.. doesn't get anything back from the server, resends 'hi guys'... waits.. *then* gets the first ack.. and breaks outta the loop but in the meantime the server's recieved *two* 'hi guys' and displays them both.

What would be needed would yeah be an id to be sent with the message, jus an extra 4 random bytes so that consecutive messages with the same 4byte tag *and* the same text would be discarded server-side, that way the client can keep resendin till the cows (or hippos) come home and the server jus posts the first message to chat text and discards the rest, and assumably everyone is happy

You sure it isn't your friends playing a joke?
You sure it isn't your friends playing a joke?

~ Tiger Crossing
~ (Nonsanity)

Indeed eltee, it goes without saying that tagging UDP date with sequence numbers applies in both directions.

This is a very important bug. Those who are seeing it, please raise the bug report.

Yes, which was why I was expressing surprise that it hadn't yet been fixed.

I noticed this line in my Application Data->SecondLife->logs->SecondLife.log file:

2004-11-05T13:48:01Z INFO packet_out_of_order - got packet 7853 expecting 7837 from 69.25.104.148:12036

This clearly shows that the packets are tagged with sequence numbers, and that out-of-order packet detection seems to be working fine.

Since this confirms that the ability to detect duplicate packets is available, it implies that either

1. the detection of duplicate sequence numbers is not working, or that

1. the server is sending duplicates with different sequence numbers.

There's bugged code in both possible scenarios, so send in those bug reports!