How to define byte array in vb6 and send it with Winsock

[Lazarus98]

Well in c# it would look like:

Byte[] ulaznipodaci = new Byte[] { 0x08, 0x3F, 0x20, 0x03, 0x00, 0x00, 0x05, 0x00 };
sck.Send(ulaznipodaci);

I need this kind of code in vb6. I tried:

Dim ulaznipodaci() As Byte
ulaznipodaci = Array(&H8, &H3F, &H20, &H3, &H0, &H0, &H5, &H0)
Winsock2.SendData ulaznipodaci

But this code gives me an error on the line

ulaznipodaci = Array(&H8, &H3F, &H20, &H3, &H0, &H0, &H5, &H0)

I searched google but couldn't find anything. Please help, I'm kinda new in vb6.

Thanks in advance.

[I Love VB6]

To answer your question about the array, ulaznipodaci should not be defined as byte, use variant instead

Dim ulaznipodaci As Variant

or just

Dim ulaznipodaci

ulaznipodaci = Array(&H8, &H3F, &H20, &H3, &H0, &H0, &H5, &H0)

However, this array will throw an error when you attempt to send it using Winsock so you should use something like this:

Dim ulaznipodaci(8) As Byte

ulaznipodaci(0) = &H8
ulaznipodaci(1) = &H3F
ulaznipodaci(2) = &H20
ulaznipodaci(3) = &H3
ulaznipodaci(4) = &H0
ulaznipodaci(5) = &H0
ulaznipodaci(6) = &H5
ulaznipodaci(7) = &H0

Winsock2.SendData ulaznipodaci

[Lazarus98]

But then I get error message: Run-time error '40018': Unsupported variant types
on the Winsock2.SendData
Why...?

[dilettante]

Because that's the wrong answer.

There isn't any "byte array literal" construct in VB. So you have to do something like load it from a file, a resource, or construct it in code.

For example you can write a function that accepts a String of hex digits, Base64, etc. and returns the corresponding Byte array.

[I Love VB6]

But then I get error message: Run-time error '40018': Unsupported variant types
on the Winsock2.SendData
Why...?

See my post #2 again

[Lazarus98]

Yeah it does work, thanks! But still there's another problem. If I try to send two packets at the same command, for example:
Dim ulaznipodaci(8) As Byte

ulaznipodaci(0) = &H8 '09 0F 3C FC 32 34 20 20 01
ulaznipodaci(1) = &H3F
ulaznipodaci(2) = &H20
ulaznipodaci(3) = &H3
ulaznipodaci(4) = &H0
ulaznipodaci(5) = &H0
ulaznipodaci(6) = &H5
ulaznipodaci(7) = &H0
Winsock2.SendData ulaznipodaci
Dim ulaznipodaci2(9) As Byte
ulaznipodaci2(0) = &H9
ulaznipodaci2(1) = &HF
ulaznipodaci2(2) = &H3C
ulaznipodaci2(3) = &HFC
ulaznipodaci2(4) = &H32
ulaznipodaci2(5) = &H34
ulaznipodaci2(6) = &H20
ulaznipodaci2(7) = &H20
ulaznipodaci2(8) = &H1
Winsock2.SendData ulaznipodaci2

Instead of sending 2 seperated packets, it sends these 2 as one packet.
I also tried to make 2 commands, and first send 1packet, and then second, but when i press command2 i get an error: Run-time error '40006': Wrong protocol or connection state for the requested transaction or request

[Lazarus98]

Do you know where I can read more detailed about it? Or can you give an example? @dilettante

[I Love VB6]

Works for me. You should show your code - both sender and receiver

NOTE:

As a general rule when you send data Winsock does not guarantee that the data will be sent in it's entirety. It could be sent in chunks of any given size. It's up to the receiver how to parse through the data separating it into meaningful segments. Usually, you will use delimeters to signal the end of a particular set of data. Another way, if you can't do any data delimiting as in the case of a video or music file is to just keep on receiving the data each time it enters the DataArrival event and concatenating it to the previous data until the receiver's close event is fired then you will have all the data. There's many other ways to capture the data like sending start/end codes, data lengths, etc. There's many examples of Winsock usage in the Database here. Do a search on Winsock, Chat. You say you are new to VB. Winsock is not the best place to start learning VB. It can get quite complex and if you do not understand Winsock you will wind up over your head. So if it's Winsock you want to learn then grab some samples from here and study the code and try to figure things out. When you get stuck open a thread on particular problems you are having code wise

Your Run-time error '40006': Wrong protocol or connection state for the requested transaction or request was caused because something in your Command2 button code was done but one of your Winsock controls was not in the correct state to perform or take action on that operation like maybe it was closed and then you attempted to send some data. This is why I asked you to post your code

[DataMiser]

Instead of sending 2 seperated packets, it sends these 2 as one packet.
I also tried to make 2 commands, and first send 1packet, and then second, but when i press command2 i get an error: Run-time error '40006': Wrong protocol or connection state for the requested transaction or request

That is just the way it works, never assume that everything you send will arrive in one read nor that each thing you send will arrive separately. The winsock will notify when something has arrived this could be a full transaction, part of a transaction or multiple transactions. It is up to you to format your transmissions in such a way that you can tell when you have a complete transaction as well as being able to tell where one stops and the next begins.

One commonly used method is to end each transmission with a CR or other such character then buffer the data as it arrives and look in the buffer for that character. When you find it then you know that whatever is before that character is a transaction that can be processed, if anything follows it then it needs to be saved in the buffer as the next transaction(s).

Of course a CR is not always the way to go as it could appear in the data in many cases and in those cases it is not suitable. In your case maybe you just need a number of bytes or maybe a specific group of bytes as a delimiter the main thing is that you can combine and separate the data properly as it arrives.

If you blindly send and receive you can never be sure how it is going to work, it may even work in a few tests and then fail later. Always make sure that you frame your data in a way that the receiver can identify it.

[Lazarus98]

Works for me. You should show your code - both sender and receiver

NOTE:

As a general rule when you send data Winsock does not guarantee that the data will be sent in it's entirety. It could be sent in chunks of any given size. It's up to the receiver how to parse through the data separating it into meaningful segments. Usually, you will use delimeters to signal the end of a particular set of data. Another way, if you can't do any data delimiting as in the case of a video or music file is to just keep on receiving the data each time it enters the DataArrival event and concatenating it to the previous data until the receiver's close event is fired then you will have all the data. There's many other ways to capture the data like sending start/end codes, data lengths, etc. There's many examples of Winsock usage in the Database here. Do a search on Winsock, Chat. You say you are new to VB. Winsock is not the best place to start learning VB. It can get quite complex and if you do not understand Winsock you will wind up over your head. So if it's Winsock you want to learn then grab some samples from here and study the code and try to figure things out. When you get stuck open a thread on particular problems you are having code wise

Your Run-time error '40006': Wrong protocol or connection state for the requested transaction or request was caused because something in your Command2 button code was done but one of your Winsock controls was not in the correct state to perform or take action on that operation like maybe it was closed and then you attempted to send some data. This is why I asked you to post your code

Well yeah, it did work, there was a problem in other part of the code which i fixed, thanks. But still, I face the next problem which is receive packet in bytes.
I'm making a bot for the game(multiplayer game, not mine), so server is game server. I'll need to receive packets as bytes in order to get playerID's, player list, etc.
I looked how to use winsock in chat applications but there, winsock sends and receive only string. I couldn't find this anywhere. So my last question is how to receive packet as bytes, when I do not know the length of the packet (i can't know the length of player names). Is it even possible?
Thanks in advance.

[I Love VB6]

If you send byte array to server it will receive it as a string by default. Why are you so adamant on having a byte array at the other end. Again, the data coming in will be in chunks so you will still have the ordeal of extracting out the various pieces you need after you get the entire data of one request. The chat examples should give you all the info you need to do this

Anyway if you really want to use byte array then this in the DataArrival:

Dim Bytes() As Byte

Winsock.GetData Bytes

Now Bytes contains your byte array sent from a client

[Schmidt]

If you send byte array to server it will receive it as a string by default...

That's not correct - the winsock-API (especially TCP) will always transfer the "raw-data" you put in
unchanged (not mangling it on its own, in its receive-buffers) - so if one puts a ByteArray (as raw-data)
in on one end, it will come out as an unchanged ByteArray on the other end as well.

The only thing one has to keep in mind - is to use the appropriate read-out-method
of the current Winsock-Wrapper (which you already covered in your reply).

One way which is often used by RawData-protocols (ByteArray-based ones), is to prefix
the real Data with a length-header of 4Bytes (using a 32Bit-VB-LongType for example).

So, the first 4 Bytes one will receive in such a protocol will already describe the length
of "what's still to come-in". One can use that information *without* having to parse
"within the UserData-Blob" for certain Split-Markers (as e.g. per InstrB).

There's a slight risk of "loosing synchronization" with that kind of approach (when you attempt to read
the length-descriptor from the wrong position in the stream, can happen e.g. when the receiver did not
read each and every byte from the socket, or is not fast enought to keep up) ...

But an extra "start-marker" (e.g. a simple "FourCC") before the length-descriptor
can help with that - so the real prefix-length would then be 8Bytes instead of 4:
<FourCC=4Bytes><LenDescriptor=4Bytes><RawData-ByteArray>... a.s.o.

Olaf

[I Love VB6]

In my DataArrival I use this

Dim s As String

Winsock1.GetData s

and s will have a string of the data that my client sent as a byte array and that tells me what I said was correct

[Lazarus98]

If you send byte array to server it will receive it as a string by default. Why are you so adamant on having a byte array at the other end. Again, the data coming in will be in chunks so you will still have the ordeal of extracting out the various pieces you need after you get the entire data of one request. The chat examples should give you all the info you need to do this

Anyway if you really want to use byte array then this in the DataArrival:

Dim Bytes() As Byte

Winsock.GetData Bytes

Now Bytes contains your byte array sent from a client

The reason why I need this is cuz server(in this case multiplayer game), sends to client information through these packets, and the only way for me to analyze and get information i want(Player's ID, Player's name, Map's name etc.) from these packets is if I have them as bytes.
This worked perfectly, thanks again!

[I Love VB6]

You're saying that's the only way for you to analyze the data but in reality you can do the same things with strings and you don't have to convert the bytes to strings later (necessary so users can read the data) but it's your program and you can have whatever you want.

[I Love VB6]

OK, Oalf, I do see where I had to specify String either as a variable or vbString as the data type in the .GetData statement in order to receive string data otherwise it will be in byte format. My bad for the misleading statement

[FunkyDexter]

I'm making a bot for the game(multiplayer game, not mine),

Our terms of service expressly prohibit asking questions on how to violate any third parties terms of service. So unless this multi player game allows the use of bots this discussion would not be allowed in this forum.

What game is this bot aimed at?

[DEXWERX]

This snippet won't win any awards for efficiency...

Dim ulaznipodaci() As Byte
ulaznipodaci = ByteArray(&H8, &H3F, &H20, &H3, &H0, &H0, &H5, &H0)
Winsock2.SendData ulaznipodaci

...

Public Function ByteArray(ParamArray Bytes()) As Byte()
    ReDim RetBytes(0 To UBound(Bytes)) As Byte
    Dim Index As Long
    For Index = 0 To UBound(Bytes)
        RetBytes(Index) = Bytes(Index)
    Next
    ByteArray = RetBytes
End Function

[Niya]

One commonly used method is to end each transmission with a CR or other such character then buffer the data as it arrives and look in the buffer for that character. When you find it then you know that whatever is before that character is a transaction that can be processed, if anything follows it then it needs to be saved in the buffer as the next transaction(s).

You should only do this when you're sending text over the wire. If you're sending binary data, a length prefix is the way to go.

[Niya]

There's a slight risk of "loosing synchronization" with that kind of approach (when you attempt to read
the length-descriptor from the wrong position in the stream, can happen e.g. when the receiver did not
read each and every byte from the socket, or is not fast enought to keep up) ...

The TCP protocol guarantees that the data will be sent and in the correct order as long as a connection is maintained. A properly written Winsock application that uses TCP should not lose synchronization ever.

[dilettante]

TCP also has flow control so there should not be any failing to keep up.

[Arnoutdv]

Start your own new thread and explain clearly what your problem is.

[Schmidt]

The TCP protocol guarantees that the data will be sent and in the correct order as long as a connection is maintained. A properly written Winsock application that uses TCP should not lose synchronization ever.

TCP also has flow control so there should not be any failing to keep up.

I was not talking about the TCP-layer, I was talking about the layer above it:
- Data-Retrieval via (win)socket-UserLand-APIs

And sure, a "properly written Winsock application" should have no problem, to stay "in sync with the incoming ByteStream".

But that "properly written"-part of course, is exactly what's not that easy to accomplish...

E.g. when you have to deal with high-traffic, concurrent scenarios, and do not use IO-Completion-Ports and also
do not use threading on the serverside (to keep processing-efforts on incoming buffers away from the Listener-Thread) -
but instead rely on the usual "async Window-Msg-based" Winsock-Handling in a single thread (which is the case e.g. in the VB6-Winsock.ocx),
and the underlying NetworkCard-Driver is working "near saturation" (near its maximum transferrate), then "weird stuff can happen"...
(been there, seen that, got the T-shirt).

Olaf

[Niya]

but instead rely on the usual "async Window-Msg-based" Winsock-Handling in a single thread (which is the case e.g. in the VB6-Winsock.ocx)

I've had this experience. It was a nightmare. I will never ever write another Winsock application in a single threaded environment ever again. One has to be a special kind of masochist to ever want to try this. It is the best way to go insane.

[Schmidt]

I've had this experience. It was a nightmare. I will never ever write another Winsock application in a single threaded environment ever again.

Just in case you mean VB6 with "single threaded environment" - it does not fall into that category of course.
(since it's perfectly possible, to write multithreaded Winsock-Servers with VB6 - just don't use the Winsock.ocx for high-traffic- serverside stuff).

Olaf