- This topic has 3 replies, 3 voices, and was last updated 6 years ago by SlackBladder.
June 4, 2014 at 2:10 pm #190603SlackBladderMember
(This is with reference to the software that ChiNa-Man uploaded).
I finally got the chat working to some degree using a server made with VB.Net.
As you may know, the chat is made with Delphi and had quite a lot of errors in it. Anyhow, I can register, login, open a private room, raise hand, change nic colours etc….
I had a big problem with the audio but after a couple of months I got it to work just fine(I thought). However, The chat would sometimes freeze on the listeners side for 10 to 15 seconds or maybe the listener even had to log off and restart.
I tracked down the problem to the server, in particular, the sending of the audio stream.
Each audio packet sent has a signature, version and datatype at the start followed by the users name and the data.
These are getting chopped off occasionally for some reason or maybe the end of the packet is getting chopped and the server is only sending half of the data, then the problem occurs. The sender is unaffected and so is the server but all the other chats get frozen for a certain time.
I know that packet loss is an issue so a couple of things I’ve done is:-
If packet.startswith(signature, version and datatype) then (let it continue, else reject it)
if packet.endswith(x) then (let it continue, else reject it)
This works a lot better although a slight break is heard but the problem is still there. Packet sizes are fairly stable although they do vary from time to time without causing any problems, other times the chat freezes again and we’re back to square one.
Does anyone know of anything else I can try as I’m totally frustrated with this. There doesn’t seem to be any point of continuing with the project if I can’t get passed this issue, after all, what good is a chat without sound?
Thanks in advance.
SB.November 26, 2014 at 10:29 pm #190606SlackBladderMember
Ok, I believe I have found the problem, namely ‘bufferbloat’.
Most people are connecting via Ethernet and don’t seem to have any problems, however,
when people use wifi and/or doing a speedtest then it occurs.
As its a tcp connection and although I’m using an async method on the server, when the problem hits, the server is blocking other messages until it regains its composure after the bloat. All too late by that time. I’m thinking of moving to UDP as advised by a couple of people.
Just a heads up if others are using the same software.
SBNovember 27, 2014 at 1:08 am #190605ChikeMember
TCP protocol was particulary made NOT to lose any data, at least until the connection is lost, if what you call packets are chopped than there is something wrong with the code (e.g.assuming a full packet can always be read from the stream)
UDP will solve this (assuming audio packet can always fot UDP packet) in the sense that packets won’t be chopped, but they will be lost.
And finally, .NET is not the kind of language you want to write servers with.April 9, 2016 at 7:04 pm #190604JohnnyBiggumsMember
Any chance you can share the fixed client source code with me ?
I have a server for this, I just need the client.
It has too many errors for me to fix bud.
- You must be logged in to reply to this topic.