Speeding up Winsock

... Searched ...

I am having an issue with winsock outputting fast enough...
Winsock 1 is receiving a connection from another client then pushing the data to the clients connected to winsock 2. The separation of sockets allows different ports & easier handling of my application, as you can see in the code.

The Winsock 1 is working fine receiving the data, but it is having issues spitting it all out to even just one client. I plan on offering many more than what is being tested. The software as far as I can tell is delaying the stream 1 second for every one minute it is being connected... A disconnect/reconnect does the trick to sync it back up.

My question, is there any ways I can do to opimize my current code, as well as if the stream is lagging anyway to say "drop these packets" and continue, as it is in a streaming situation.

The other client is sending a data byte stream at 64 bytes per write (packet?) Is this a good number, I'm trying to reduce the latency to no more than one or two seconds, close to none would be wonderful. Too bad visual basic doesn't support sockets???

----
Any help appreciated.

Here is my data arrival event. please just worry about the question asked unless it is pertains to speed.

Code:

---

Private Sub Winsock1_DataArrival(Index As Integer, ByVal bytesTotal As Long)
    Dim sData As String

  'On Error GoTo Winsock1_DataArrival_Error

    Winsock1(Index).GetData sData, vbString
   
    Dim Tag As String
    If Not IsNumeric(Winsock1(Index).Tag) Then
        Tag = StrConv(sData, vbFromUnicode)
        If IsNumeric(Tag) Then
            Winsock1(Index).Tag = Tag
            Open "C:\ac_" + Str(Tag) + ".wav" For Binary Access Write Lock Write As #iFileNo
            ' Write Header Here
            Set ITM = List1.ListItems.Add(1, "w" & Index, Tag)
            Debug.Print Tag
        Else
            Exit Sub
        End If
    Else
        'Put #iFileNo, , sData
       
        ' Match sID Time & Distribute Data to all clients.
        Dim sID As String
        Dim i As Integer
        sID = Winsock1(Index).Tag
       
       
        For i = 1 To Winsock2.UBound
            If Winsock2(i).Tag = sID And Winsock2(i).State = sckConnected Then
                Winsock2(i).SendData sData
            End If

        Next
       
    End If

Winsock1_DataArrival_Error:
    If Err.Number = 340 Then
        'Subtract From Online Users
        Exit Sub
    ElseIf Err.Number = 52 Then
        Exit Sub
    ElseIf Err.Number = 0 Then
    ElseIf Err.Number = 55 Then
       
    Else
        MsgBox Err.Number & Err.Description
    End If

End Sub

---

*Bump

Surely there is something

I think that having a packet of only 64 bytes is way too low, I usually send in 4KBytes packets.

See this thread to see how data is send/received:
http://www.vbforums.com/showthread.php?t=377648

What if, you put your loop of sending out all the data in your socket array first, then deal with your file handling hud you currently have first in line?

Quote:

---

Originally Posted by CVMichael

I think that having a packet of only 64 bytes is way too low, I usually send in 4KBytes packets.

See this thread to see how data is send/received:
http://www.vbforums.com/showthread.php?t=377648

---

4K? Well I want the software to have latency, 4K would create too much would it not?

----

And spajeoly, that really doesn't make sense, can you pseudo code it.. your saying move all my code around, currently my app isn't even writing to the text file, i commented it out to see if it improved anything.

Quote:

---

Originally Posted by DJHotIce

4K? Well I want the software to have latency, 4K would create too much would it not?

---

So, let me get this straight.... you want your program to send data slow ? or what exactly do you mean by "latency" ?

latency, being the amount of time the data arrives to the server and being pushed back out, it incurs some amount of processing time ... latency.

My program is a stream of audio, and for every 1 minute of playing it is getting delayed 1 second. That is my issue

So your saying increasing the buffer in my application would help it get faster, i don't quite exactly see. (Edumacate me here :))

I used to have the buffer at 1/2 K being transmitted, i'll run some more tests tommorrow trying 4k if your saying that will work...

Again CV Thanks.

What kind of program is this? Voice chat or something? What kind of audio are you sending (uncompressed WAV?). There is always going to be some latency especially in audio streaming.

You could go and send 10MB at a time but even then, TCP will split up the data and handle the packets itself. That's something you don't really have any control over.

In most streaming audio, the server will spit the data out as fast as possible and the client will buffer the data until enough is there to play the stream, and allow it enough time to download the rest until it has reached the next point in the stream.

For example, an audio stream that is 30 seconds long, the client could wait and buffer at least 15 seconds. Allowing it 15 seconds to download the rest so it will play through it without skipping.

Not sure if this is related to your question. CVMichael has more experience with voice-network stuff than I do.

Quote:

---

Originally Posted by DJHotIce

The Winsock 1 is working fine receiving the data, but it is having issues spitting it all out to even just one client. I plan on offering many more than what is being tested. The software as far as I can tell is delaying the stream 1 second for every one minute it is being connected... A disconnect/reconnect does the trick to sync it back up.

---

Quote:

---

Originally Posted by DJHotIce

latency, being the amount of time the data arrives to the server and being pushed back out, it incurs some amount of processing time ... latency.

My program is a stream of audio, and for every 1 minute of playing it is getting delayed 1 second. That is my issue

---

NOW things start to make sense.....

There are many questions to ask... like:
Do you encode the wave stream (to MP3 or something like that) ?
How do you play the stream ? (using DirectSound ?)
What winsock protocol do you use ? (TCP or UDP ?)
Do you use buffers ? (or do you play the sound as it comes ?)

Before I get the ansers from you, let me tell you how I did my voice chat program:
I used the UDP protocol because it's faster and UDP protocol does not wait for you to fill it's buffer to send the data. What I mean is, TCP protocol has a certain "rule" to meet, and then it sends the data. So it sends the data either when the buffer is reaching a certain size (but I don't know what is that size), and a certain timeout... for example, if you send 64 at one time, it will certanly not send the data right away because I'm sure that's too little to fill it's buffer size. So it will wait until you enter more packets into the buffer and only then it will send... and that is if it did not reach the time-out. If it takes a long time to fill it's buffer threshold, then it will send whatever it has in the buffer when it's reaching the time-out (and I don't know what that is either, but it should be around 100 ms (i'm guessing)).

So... in short, if you want to get the best speed, then use UDP protocol.
But that won't solve all your problems, by switching to UDP, you gain only a few milliseconds.

Next step, is how you handle the data (buffers).
So, the way I did it: On the sender side, I encode to MP3, as soon as the encoder is done, I send the data (using UDP), so this part is simple.
On the receiving side, I don't play the data right away, because it will be too many gaps between the packets. I decode the MP3 data to wave, and I buffer the data. So incomming data I append to the end of the buffer (wavebuffer), and when I have enough data to play (size of buffer to play (size of DirectSound buffer) * 1.5), then I read from the beginning of the wavebuffer, and send to DirectSound buffer. After I copy the data to DirectSound buffer, then I delete the beginning of the wavebuffer by shifting the data.
And when it does happen that DirectSound needs data, and there is not enough in the wavebuffer, then I send a silence buffer to DirectSound, and I buffer in the wavebuffer enough so it does not happen again (i.e. I buffer DirectSound buffer size * 1.5). So I don't disconnect/reconnect this way...
By the way... the DirecSound buffer size is 1/15 of a second, so when I previously said I buffer DirecSound buffer size * 1.5, that means 1000/15*1.5=133 milliseconds, therefore the delay is not very big.

CV, my java applet is created to use the currently available classes on the java API, so I'm forced to using wave encoding, it is very low res though. I'm working on trying to get it into mu-law encoding, still working on that in java. Pretty novice when it comes to java. Encoding to Mp3 would mean I would have to have my applet install another add on which I'm trying to prevent, I'm just trying to use the existing tools available to me. Otherwise I'd have to use the JMF (Java Media Framework) which would require a newer version and installation of java. Not really easy for my end users.

I am also using TCP, simply because it's more reliable, i don't quite now how to handle UDP and the complications dealing with it.

I am handling my read on my client app using a very small buffer 64 bits. When it fills up it writes it to the soundcard (using java's implementation). The broadcaster again fills up the buffer 64 bits then transmits.

I am suspecting it is the server because I can disconnect my stream from broadcaster, and it is still transmitting data, so it is storing it in memory I guess... Memory problem I suspect.

------
I remember when we discussed last that the audio we are using should be just fine across even a 56k modem.

I'm not sure what kind of help you want... I don't know java, and this is not a java forum...

CV, the java isn't the help I'm seeking :)

I am pretty positive that my VB application isn't outputting the data fast enough, even though it is being received fast. I'm looking for ways to improve the speed of the code, or if the winsock\vb app is just too slow to handle what I'm doing...

BTW I got both my java apps to send 4k bits of data, and i noticed "slurred" speech, was quite funny.

Right... the code in the first post...

So let see if I got this right:
The Java program records the sound, and sends it to a VB server, then the server "broadcasts" to the clients connected to it, right ?

So... if the Java program sends 64 bytes at the time, what is the packet size you receive on the server side ?

For example, what do you get if you add the line: "Debug.Print bytesTotal" in the Winsock1_DataArrival event ?

Exactly, this is like a shoutcast/icecast server w/o mp3 support I guess.

Also the debug window is showing 4096 like I expect :) (4 K buffer as you suggested)

I don't know what to tell you... you did not give enough information to draw a conclusion on what is wrong with your code...

You only posted what you have in the DataArrival event, that's not enough...

so your saying from the information listed above that that should be enough for a program to easily send out that amount of data in a fast fashion?

Is There any way I can create some kinda benchmark debug code, to see just how long certain portions are taking in the data arrival event? This way I can pin-point exactly the right lines that are taking the most amount of time, at least 1/8th of a second.

Are you sure you've properly analyzed the symptoms?

For one thing you've fallen prey to The Packet Fallacy. TCP connections are streams. There are no "packets" being either written or read at the application level. So making the assumptions the code you showed above does will lead to problems.

At least two factors could be at work here: Nagling and TCP windowing. Both of these will contribute to your GetData calls not returning chunks of data exactly equal to the chunks of data you sent in each send at the other end. That funky stuff you're doing with String variables and Tag properties is probably where you're most vulnerable here.

You're also using String variables for some bizarre reason with data that is clearly binary. Use Byte arrays instead to avoid inadvertant data corruption and a better overall experience.

You'll find that a VB6 program compiled to native code will always outperform any Java program hands down. That is unless it's poorly coded. VB6 native code can perform at levels quite similar to that of C programs unless foolish things are done. You are also asking a lot of this VB program, mostly in terms of relaying a ton of quickly-arriving incoming data to a number of clients.


Dinking around with 64 byte chunks of data will prove a performance killer. You're doing too much thrashing around here.

Again we can't see where you're getting the data from. I guess that's your "other client" - possibly Java too? Why would you spend so much overhead by dribbling data in 64 byte chunks? For best performance this "other client" should be blasting the data to this VB program in whatever chunks it can grab itself. If it is reading from disk to get the data it should be reading (and sending) chunks of 32K to 64K. This would be for disk I/O optimization though.

We don't have enough information to make further suggestions. I'm not fully aware of the characteristics of the "sockets" (typically blocking sockets) provided by your Java library, since you didn't say what library you're using. Perhaps the standard one?

Standard Java sockets are incredibly weak. Typically you'd be forced to multithread to accomplish much of anything with them besides a single-stream passthrough. VB's Winsock control is worth 100 (or more) Java sockets. I've pushed a VB program using Winsock controls to over 3000 clients on an old Celeron 400 machine using a few registry tweaks... though admittedly I wasn't keeping each one very busy. ;)

Feel free to rewrite your code in Java to show us how wonderful it is. :lol:


Don't feel too bad. Most VB programmers don't seem to have a clue how to use the Winsock control properly, despite the fact that the documentation is pretty explicit - to those who read it carefully.

Look here in the Networking forum for lots of information. Be careful though, a lot of misinformation is being spread there. For example the thread lnked above, which is full of Cargo Cult Programming.

> Are you sure you've properly analyzed the symptoms?
No.

At least two factors could be at work here: Nagling and TCP windowing. Both of these will contribute to your GetData calls not returning chunks of data exactly equal to the chunks of data you sent in each send at the other end.
> I am receiving all data, just delayed, and in proper byte form.

>That funky stuff you're doing with String variables and Tag properties is probably where you're most vulnerable here.
What would you suggest then?

> You're also using String variables for some bizarre reason with data that is clearly binary. Use Byte arrays instead to avoid inadvertant data corruption and a better overall experience.
Wouldn't doing that create a buffer? Please go into more detail if not.

>Again we can't see where you're getting the data from. I guess that's your "other client" - possibly Java too?
An applet, yes.

>Why would you spend so much overhead by dribbling data in 64 byte chunks?
to reduce latency

> For best performance this "other client" should be blasting the data to this VB program in whatever chunks it can grab itself.

> If it is reading from disk to get the data it should be reading (and sending) chunks of 32K to 64K. This would be for disk I/O optimization though.
I'm reading from a soundcard's microphone

> ... Perhaps the standard one?
Correct

> Feel free to rewrite your code in Java to show us how wonderful it is. :lol:
I'm trying to avoid that ;)

> Don't feel too bad. Most VB programmers don't seem to have a clue how to use the Winsock control properly, despite the fact that the documentation is pretty explicit - to those who read it carefully.
I don't feel too bad, but pretty crummy. I would love to learn how to use it properly, where is this documentation, i would LOVE to get my hands on it.

> Look here in the Networking forum for lots of information. Be careful though, a lot of misinformation is being spread there. For example the thread lnked above, which is full of Cargo Cult Programming
I Would love to learn best practices :)

Thanks for the response :cool:

Bump, sigh, again...

Ok, let's see if I can offer some more productive comments.

The first question I have is about your sampling rate since you're taking in microphone sound samples. How much elapsed speech/sound time does 64 bytes represent? I'm assuming little or no compression, so each 64 bytes must pretty much represent the same amount of time.

This will help us understand the data arrival rate and thus help calculate the acceptable latency in bytes once we know what you can accept in seconds (or fractions)... so we'll need to know that too.

So far then I have two questions:

How much "time" does 64 bytes represent (or what is your sampling rate in bytes per second)?

What is the acceptable lag from microphone to output at the client?

Some lag is out of our control because there'll be some in converting bytes and bits into audio output at the clients as well of course.

Your VB program that is relaying this data to clients will encounter some inevitable buffering at levels you have little control over. Part of this is due to the Nagle algorithm, part of it due to TCP window optimization.

Your Java (or whatever) source program that's capturing sound to a bytestream and passing it to the relay/distribution program will be subject to these same factors. It has little to do with using Java, VB, C, or anything else.


It is possible to disable Nagling in a VB program. I don't know enough about your Java program's environment to comment about that.

Disabling Nagling is almost always a bad idea though.

http://en.wikipedia.org/wiki/Nagle's_algorithm

By disabling Nagling you may actually increase the latency because you're adding a ton of overhead. The presence of Nagling means that by sending 64-byte chunks you are actually fighting TCP's attempts to optimize throughput. Most likely much larger chunks are being strung together and sent by TCP right now, plus you have all of the other overhead of handling so many 64-byte chunks instead of handling fewer larger chunks.

Nagling basically buffers stuff up until it has "enough to be worth sending" or a certain amount of time has passed. Yet turning it off can result in The Tinygram Problem.


There is also a risk of "Silly Window Syndrome." This is independent of the nagling issue. It has more to do with sending rapidly streaming data in chunks of from 1024 to 2048 bytes. It is normally much better for TCP if you send fast-stream data in chunks (SendData calls) of 32K to just under 64K bytes. Multiple shorter SendData calls are fine, as long as they happen in extremely fast succession. On a 100M bps LAN it is almost impossible to fire the data fast enough with short SendData calls though. "Extremely fast" changes with the end-to-end net data rate of the network and gets shorter quickly as network data rates increase.

http://en.wikipedia.org/wiki/Silly_window_syndrome


Basically, those 64-byte chunks are killing you here! And most of the problem is at the source, not in this VB relay/distribution program.


But on top of all that your VB program is a victim of The Packet Fallacy.

The VB program will not reliably receive the same chunks that the source (Java?) program sent. It'll get all of the bytes and get them in the proper sequence, but they will not be in fragments received by GetData the same way they were sent by the source program:

Sent:

1234567890 1234567890 1234567890 1234567890

Received:

1234567890123456789012 345678 9012345 67890

In reality if the sending program is "slow" this unexpected fragment consolidation will be infrequent - but frequent enough to mess things up! If the end-to-end network is "slow" things get even worse though, since your program becomes relatively "fast" (relative to the raw network throughput).


Your code seems to expect something that "IsNumeric" (or "Not IsNumeric" - the logic is hard to follow) as a lead-in or something. If this is true, that is if you are expecting the "first bytes" of the result of a GetData to have special significance, your program will make mistakes, lose data, etc.

This is precisely why a TCP receiver needs to "buffer" inbound data at the application level. This buffer must be examined for something in the content to tell you where the boundaries are, then you split things out on the basis of that "something," and finally process the restored sent-chunks (messages or datagrams).


I'm not suggesting you can't make this work. It is exactly why a lot of streaming audio and most streaming video uses UDP though whenever possible. TCP will add delays and perform low-level buffering and windowing in an attempt to optimize the use of the connection and the network it operates over while guaranteeing delivery and sequence of the data stream. It was not meant as a real-time signaling system.

dilettante, you obviously have done your research on this topic and I thank you once again for your post.

I have access to nagles algorithm in java. Never even heard about it when I started programming this. Are you suggesting I do 8k bits to speed up my application? Seems high... Here is the sniplet of java code, just the variables for my audio format.
Answer to Q1:

Code:

---

                float sampleRate = 8000.0F;
                //8000,11025,16000,22050,44100
                int sampleSizeInBits = 8;
                //8,16
                int channels = 1;
                //1,2
                boolean signed = true;
                //true,false
                boolean bigEndian = true;

---

Answer to Q2:
An acceptable lag to me would be up to 2-3 seconds.
----

If your suggesting UDP, I can certainly try to go that route, I figured why not use TCP since it is reliable, but seems to me I spec'd that wrong. Never have used it before that's another reason, as well as the out of order issues and unreliability. I tried to do as much research as I could into this application to determine your end results... The old parable count your costs before you build. Coming from a TCP background would UDP be harder\easier for me to implement. (Within VB)
-----
Let me understand this correctly, disabling nagles algorithm in my application would cause my program to actually send more data than is necessarily required.

With Nagle's algorithm turned off you force more small TCP packets to be sent, and each has something around 40 bytes of overhead. Each has to be acked, though several can be along the way before the acks come back.

It can slow things down though.

Sounds like you're sampling 8K bytes/sec? With a double lag sending 8K chunks might be at your tolerance level for latency. Maybe 4K?

Tried 4 K Chunks, 8 K Chunks, now 16 K chunks, still delaying as always.

I'm sure it has to do with that code I originally posted. I plan on steering away from the .tag using an array, would this be best?

I ran that code using the vb "previewer" so it wasn't compiled, however I shouldn't gain to much in terms of speed huh?

When testing the speed of anything, always compile it - the speed differences can be ridiculous (as well as being more consistent).

The more I think about this situation the more confused I get.

If you are indeed sampling at about 8K bits per second that means 1K bytes per second. Even sending 1K byte chunks at this rate should not result in significant Nagle delays.

It's as if something else is going on here. What is going on in the client?


Finally, what Service Pack is your VB6 at? There were several known flaws in the Winsock control that were never fixed until SP6. Some of them sound suspicious in light of the symptoms you're experiencing, relating to lost events that prevent data from being processed expeditiously.

Inside the client it is using a byte array to gather the data up. Once the "buffer" fills up (it blocks until it does), it moves over to the next line of code which pushes the data via the java socket to the vb app (again using the byte array). After it is pushed out, it is flushed. It does this in an infinite loop until the program ends. Inside that loop it is only a 3 piece line of code. An integer declaration which reads the data. then the sending of the data for the remaining two pieces of code... I'm gonna re-write my vb code to see if it improves the speed. Using an array instead of Tag, I am aware you gain speed using an integer vs string, in ways of binary boolean logic. (Is that correct usage of words)

------
VB version is ... 6.0.8169 then it says version 8176

You are missing a number of fixes then and may be back at SP4 or 5.

In the VB6 IDE try the "Help|About..." menu selection to see the version. You should be at something more like Version 9782, and near the top of the "About" dialog it should mention what Service Pack level you are at.

I've looked over your code a number of times now, and I don't see anything that should cause extreme delays. Of course running it within the IDE will slow things quite a bit.

Removing And Winsock2(i).State = sckConnected seemed to speed up the prog a little. Decreased buffer from the pushing client, improved it a little. This is a complete compiled program. I'm investigating if it could be my pulling client as well. If it is getting the data and just storing it then it may not be vb at all.

I may be begining to think it may be a faulty designed client... Gonna dig around.

Okay, got my buffer on my pull client on both the byte array of the socket to 1024 (very low), and the audio buffer of 1024... The pushing client is outputting at 1024 * 4 so 4K bytes.

When I stop my push client the one that sends to the server i see in my windows task manager it stops sending (drastic reduction in network traffic). Then I still see data moving, about half of that as my player is still receiving data. Once it flat lines I notice not even 1/2 a second later it quits.

My lag formula can be said at lag (in seconds) = (minutes / 60) + 2
I believe that is correct, initially starts off with 2 seconds lag, then for every minute add another second to the overall delay.

Seems to me that it is still getting hung up on the VB server code mentioned. Should I turn that into a function for increased speed at least the top part? Arrays seemed to improve performance slightly.

Should I show you what settings I'm using when compiling this app? I know there are advanced settings and that too can make a difference.

Might be off-base here, but the fact that you're getting increasing lag sounds to me like you're not removing stuff from the buffer after it has been sent/received or played/processed.

I would monitor the memory usage of the server (and client) and maybe even do some debugging on the data to make sure you're not sending data that has already been sent (or put into the buffer).

I haven't read the whole thread so I could be completely off base. ;)

well... so far nothing concrete except saying that I might be using a wrong vb version.

-------
If I don't get a solution today I'm gonna have to start porting this to java, which is multithreaded, and vb isn't, I believe that is my stumbling block at this moment.

Not "wrong" just broken. Seriously, have you applied SP 6?

List of bugs that are fixed in Visual Studio 6.0 Service Pack 6

If I have interpreted your audio sampling rate correctly most of the concerns about the ways data might be delayed aren't important here. The 64 byte sends were the only remaining issue and at this rate that shouldn't result in delays of the length you're seeing. Maybe if you had 30 clients connected, but not with just one.

There were some very specific bugs relating to lost events and data arrival that SP 6 fixed.

If things were this tricky to get working at these low data rates people would notice it in the silliest little chat programs. I've done file transfers using the Winsock control that easily moved 1MB of data over a fast LAN in under a second.

If you are wondering why I stopped giving my oppinion is that you did not give enough information, and when asked to give more info, it was not usefull info...

Actually, we need to see code to figure out what is wrong, and you did not provide much of that either...

Also, you do not seem to be able to debug your program... if you did, I'm pretty sure you would not even had asked for help...

Right now you don't even know where the problem is, you are just speculating...

I don't know what else to say... we need to see code to draw more conclusions on what the problem is.

Entire Contents of VB project attached.

Also posting a screenshot of my task manager, this is when I updated the service pack, ran into issues actually installing it, but I updated system runtime files and that created a more stable (flat-line) of data flowing between the system...

BTW i am on a G connection on the laptop, the computer the server is running on is the wireless router connected to a 10/100 lan connection, on a p4 xp-home machine. 512K of ram. It's fast and resources are not a problem on that system, program was running around 3-4% processor usage.

This is the complete project enclosed. Any more info?

here's the screen shot of the computer running the clients, not the server. It would be safe to say that bandwidth would be 1/2 that for one client connection.

-----
More information... I started up another client on the same system after the other one ran for 5 minutes, the delay was noticiable. The other client started streaming and had a minimal delay, then progressively got longer.

Not sure what that means, it confuses me... Does it mean that VB is getting stuck on the loop... I can't infer that. Could it be my data retrieval code on my java client. Possibly. But data is still moving even after a disconnect indicating some type of buffer on the vb client. Could this be a problem with the winsock control? How can I check? Is there a way to detect version number?

I sense there could be a problem larger than VB itself. I know I am speculating here, but I'm trying to work this out together, and using problem solving using what information I have available.
------
Since i wasn't able to get sp6 installed correctly, could somebody re-compile that to make it all good? or is does SP6 also update dlls as well.

When I try to open the project it says that wav.bas is missing....

here that portion is... I believe that is code you wrote, and was playing around with it.

Additionally I extracted that to the desktop, sorry...

OK, I looked at the code, it's a bit messy but that's probably because all the things you've been trying to do...

The only thing I see that does not look right, is how you get the IDs (Tags)...

Especially the one that the server (java program) sends to the Alternastream program.

The way you have the code, implies that the java program will send an ID, then wait for data to send, and only then continue to send the wave data.

Because if it's NOT... then you got a problem. The way the code is made now, if the java program sends the ID (Tag), and right away sends the wave data, then the ID will be concatenated to the wave data, and therefore this line "If IsNumeric(Tag2) Then" will return FALSE...
Same with everything where you get the Tag... You either should send the tag with a constant length, so then you read N'th first numbers even if the wave data follows it, you still read the right Tag. Or... send a reply back, something like "received tag", then the sender can go ahead to send the wave data.
So, at this line "If bcTag(Index) = 0 Then" (first time you get data), if the data is MORE than what you expect (more than the tag), then you should read the tag, and ALSO go to the section where you read the wave data, i.e. like this:

vb Code:

If bcTag(Index) = 0 Then
            Tag2 = StrConv(sData, vbFromUnicode)
            If IsNumeric(Tag2) Then
                If Tag2 > 0 Then
                    bcTag(Index) = Tag2
                    'Open "C:\ac_" + Str(Tag) + ".wav" For Binary Access Write Lock Write As #iFileNo
                    ' Write Header Here
                    Set ITM = List1.ListItems.Add(1, "w" & Index, Tag2)
                    Debug.Print Tag + " " + bytesTotal
                End If
            Else
                'Winsock1(Index).Close
                Exit Sub
            End If
 
            ' change here to the whatever you decide to use
            ' if there is more data, jump to send the data
            If Len(sData) > tag_length Then
                    '  delete the tag from the data
                    sData = Mid(sData, tag_length)
                    goto SendWave
            End If
    Else
SendWave:
        'Put #iFileNo, , sData
        
        ' Match sID Time & Distribute Data to all clients.
        Dim sID As String
        Dim i As Integer
        sID = bcTag(Index)
        
        
        For i = 1 To UBound(cTag) - 1
            If cTag(i) = sID And Winsock2(i).State = sckConnected Then
                Winsock2(i).SendData sData
            End If
 
        Next
        
    End If

I did that by putting a 4 second delay after sending a string, then the byte data gets along. I called it on the push client "Negotiating" in the future if it doesn't work it will disconnect the client.

So essentially it is what you are saying, and it works out great.

I should add the SP 6 does indeed update DLLs and OCXs.

The Winsock control has several problems that were never fixed until SP 6.

i'm having issues updating, my disc ended up getting scratched and it still compiles fine, but the msdn is missing, and i think i had a few errors that showed up on the install but it still continued. Is there any other way I can update to sp6?

I would think the SP 6 download should install just fine without using the original CDs:

Service Pack 6

If your VB6 CDs have gone bad though... these are hard to replace today. Sorry to hear that.

Yeah i can get a hold of the installers no problemo.
Shows up in Add/Remove Progs

just the installer says because setup was unable to find the visual studio, setup aborted or something along those lines... googled without avail :( seems others have had the same problem although isolated, I did install vb 2005 to see what the hype was all about though, uninstalled same problem.