I am having lots of trouble with this packet because whenever I recieve it I get a big cluster of them all in one packet....I am usally getting about 5-7 packets shuved into one. Does anyone had this problem or know of a solution?

Any Help would be gladly appreciated...

Edit:

You can also reach me on aim, my name is KKBlazekK

[quote author=Kk)Blaze(kK link=board=17;threadid=8140;start=0#msg75167 date=1092283313]
I am having lots of trouble with this packet because whenever I recieve it I get a big cluster of them all in one packet....I am usally getting about 5-7 packets shuved into one. Does anyone had this problem or know of a solution?

Any Help would be gladly appreciated...

Edit:

You can also reach me on aim, my name is KKBlazekK
[/quote]

I would suggest separating the individual packets as you receive them.

I have tried that...

Didn't work so well....

I tried something else, parsing the first packet then removing it then doing the next, but that don't work either...

heres the script...


[code]
ParsingData = Data
ParsingPoint:
ptemp = StrToHex(ParsingData)
AddChat ptemp, vbRed
ParsingLength = Mid(ptemp, 8, 2)
ParsingLength = HexToDec(ParsingLength)

Flags = 0: Ping = 0: Message = vbNullString: Product = vbNullString:


Flags = MakeLong(Mid(ParsingData, 9, 4))
Ping = MakeLong(Mid(ParsingData, 13, 4))
Username = KillNull(Mid(ParsingData, 29))
Message = KillNull(Mid(ParsingData, Len(Username) + 30))
Product = StrReverse(Left(Message, 4))
Call OnUser(Username, Flags, Message, Ping, Product)
ParsingData = Mid(ParsingData, ParsingLength, Len(ParsingData) - ParsingLength)

If Len(ParsingData) > 4 Then
GoTo ParsingPoint
Else
Exit Function
End If
[/code]

[quote author=Kk)Blaze(kK link=board=17;threadid=8140;start=0#msg75167 date=1092283313]
I am having lots of trouble with this packet because whenever I recieve it I get a big cluster of them all in one packet....[/quote]

If I understand correctly, it doesn't sound that hard at all. The packets have a header that tells you their length for a reason - use it.

Of course you could do what i do which is:-

(1) Do a recv on your socket using a length of HEADER_SIZE which is 0x04 on a bnchat connection.

(2) Copy the header buffer into a fixed length structure for easy access.

(3) The next recv event use a length of the size field in the header structure you read previously.

This works very well for me on bnchat and also saves you having to read a massive chunk of data then having to split it up with the possibility of incomplete data.

Of course this method assumes 2 things:-

(1) Your underlying socket paradigm allows you to read a data fragment then if there is still data left on the network stack raises additional events until that entire segment is read.

(2) The packet buffer you are using has sufficient space to accomodate a complete event message, which is not a problem with bnchat as the events are very small.

You people took no look at my script did you? My script gets the length from the header. It works untill the thrid packet then it screws up...

[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75201 date=1092314769]
(3) The next recv event use a length of the size field in the header structure you read previously.

This works very well for me on bnchat and also saves you having to read a massive chunk of data then having to split it up with the possibility of incomplete data.
[/quote]

You still have the possibility of incomplete data. You have to handle that in (3)...

Kind've nasty to look at. Let me clean it up a little:

[code] ParsingData = Data
ParsingPoint:
ptemp = StrToHex(ParsingData)
AddChat ptemp, vbRed
ParsingLength = Mid(ptemp, 8, 2)
ParsingLength = HexToDec(ParsingLength)

Flags = 0: Ping = 0: Message = vbNullString: Product = vbNullString:

'assuming you're in the event parsing, here?
'if not, this could be screwing you up?
Flags = MakeLong(Mid(ParsingData, 9, 4))
Ping = MakeLong(Mid(ParsingData, 13, 4))
Username = KillNull(Mid(ParsingData, 29))
Message = KillNull(Mid(ParsingData, Len(Username) + 30))
Product = StrReverse(Left(Message, 4))
Call OnUser(Username, Flags, Message, Ping, Product)
ParsingData = Mid(ParsingData, ParsingLength, Len(ParsingData) - ParsingLength)

If Len(ParsingData) > 4 Then
GoTo ParsingPoint
Else
Exit Function
End If[/code]Why are you reading the packet header from the hexadecimal string? That's not very easy to work with. Going from one source, to another, and back... that's confusing.

Also, what are you doing in case you don't receive a full complete packet? It looks like you're able to break out if you don't have at least a header, but it doesn't look like you're checking that the whole packet is there.

Try this code:
[code] ParsingData = Data
ParsingPoint:
ptemp = StrToHex(ParsingData)
AddChat ptemp, vbRed
ParsingLength = Mid(ParsingData, 3, 2)'length byte starts at the third byte
'ahh, i see now why you were converting to hexadecimal
'you need to learn how to convert from the raw string directly into the integer, not using middle-man hexadecimal
If ParsingLength > Len(ParsingData) Then
'incomplete packet
Exit Function
End If

Flags = 0: Ping = 0: Message = vbNullString: Product = vbNullString:

'assuming you're in the event parsing, here?
'if not, this could be screwing you up?
Flags = MakeLong(Mid(ParsingData, 9, 4))
Ping = MakeLong(Mid(ParsingData, 13, 4))
Username = KillNull(Mid(ParsingData, 29))
Message = KillNull(Mid(ParsingData, Len(Username) + 30))
Product = StrReverse(Left(Message, 4))
Call OnUser(Username, Flags, Message, Ping, Product)
ParsingData = Mid(ParsingData, ParsingLength, Len(ParsingData) - ParsingLength)

If Len(ParsingData) >= 4 Then
'need greaterthan or equalto, because null packet is only 4 bytes long
GoTo ParsingPoint
Else
Exit Function
End If[/code]

[quote author=Adron link=board=17;threadid=8140;start=0#msg75233 date=1092332715]
[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75201 date=1092314769]
(3) The next recv event use a length of the size field in the header structure you read previously.

This works very well for me on bnchat and also saves you having to read a massive chunk of data then having to split it up with the possibility of incomplete data.
[/quote]

You still have the possibility of incomplete data. You have to handle that in (3)...
[/quote]

There is no possibility of incomplete data my socket classes just wait on the next recv after (2) and compares the length to the header length to ensure it's complete if not it just waits for the next data fragment until the header size = the total packet size accumulated.

Try it out it;s an impossibility to break my logic :D

I have used this system for many years without ever running into incomplete data, comparing this to just reading a chunk and parsing it mine is 99% accurate.

[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75264 date=1092341876]
There is no possibility of incomplete data my socket classes just wait on the next recv after (2) and compares the length to the header length to ensure it's complete if not it just waits for the next data fragment until the header size = the total packet size accumulated.
[/quote]

Then you are handling it in (3) just like I said you had to. If you're going to recommend this solution to others, you better make it clear that they have to handle calling recv multiple times to get all the data.

You're also handling the case of incomplete headers?


It's still not a very efficient solution, not as good as receiving a large buffer and parsing it out yourself.

[quote author=Adron link=board=17;threadid=8140;start=0#msg75267 date=1092343492]
[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75264 date=1092341876]
There is no possibility of incomplete data my socket classes just wait on the next recv after (2) and compares the length to the header length to ensure it's complete if not it just waits for the next data fragment until the header size = the total packet size accumulated.
[/quote]

Then you are handling it in (3) just like I said you had to. If you're going to recommend this solution to others, you better make it clear that they have to handle calling recv multiple times to get all the data.

You're also handling the case of incomplete headers?


It's still not a very efficient solution, not as good as receiving a large buffer and parsing it out yourself.
[/quote]

First response i am just providing a basic framework which does not cover all eventualities otherwise i would be here all day, also im not going to write someones code for them, basic checks and such and standard programming practise, also if he has any specific questions i would be only to pleased to provide more information with a pm or response here.

If you feel the need to elaborate in more detail or provide some source code for him be my guest otherwise then i suggest you allow him to work the finer details for himself.

Second point yes i make all basic checks to do with lengths//structures i read the first 4 bytes for bnchat and all subsequent reads i then first check the header is intact, if thats passes my requirements then i continue and check the data length received against the actually size defined in the header, and if those both succeed then i dispatch the packet :)

Just as a note the complete message is guarenteed delivery as this is tcp/ip i.e send/acknowlege protocol if the entrire packet sent from bnet is not completley received then it will not be passed on from the network subsystem ^^ :)

Considering the sizes of normal event messages in chat im assuming bnet would send an entire message at once rather splitting it up which would mean guarenteed delivery, or at the very least it would send a complete header, and my logic handles both of these conditions with ease.

Ps. Maybe it would be more helpful if you make a contribution to the original question rather than just critising what i say.

Also forgot last point it;s actually less efficient doing it that way because you have to allocate additional resources to store the buffer and cycle time for parsing etc.

[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75269 date=1092345177]
[quote author=Adron link=board=17;threadid=8140;start=0#msg75267 date=1092343492]
[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75264 date=1092341876]
There is no possibility of incomplete data my socket classes just wait on the next recv after (2) and compares the length to the header length to ensure it's complete if not it just waits for the next data fragment until the header size = the total packet size accumulated.
[/quote]

Then you are handling it in (3) just like I said you had to. If you're going to recommend this solution to others, you better make it clear that they have to handle calling recv multiple times to get all the data.

You're also handling the case of incomplete headers?


It's still not a very efficient solution, not as good as receiving a large buffer and parsing it out yourself.
[/quote]

First response i am just providing a basic framework which does not cover all eventualities otherwise i would be here all day, also im not going to write someones code for them, basic checks and such and standard programming practise, also if he has any specific questions i would be only to pleased to provide more information with a pm or response here.

If you feel the need to elaborate in more detail or provide some source code for him be my guest otherwise then i suggest you allow him to work the finer details for himself.

Second point yes i make all basic checks to do with lengths//structures i read the first 4 bytes for bnchat and all subsequent reads i then first check the header is intact, if thats passes my requirements then i continue and check the data length received against the actually size defined in the header, and if those both succeed then i dispatch the packet :)

Just as a note the complete message is guarenteed delivery as this is tcp/ip i.e send/acknowlege protocol if the entrire packet sent from bnet is not completley received then it will not be passed on from the network subsystem ^^ :)

Considering the sizes of normal event messages in chat im assuming bnet would send an entire message at once rather splitting it up which would mean guarenteed delivery, or at the very least it would send a complete header, and my logic handles both of these conditions with ease.

Ps. Maybe it would be more helpful if you make a contribution to the original question rather than just critising what i say.

Also forgot last point it;s actually less efficient doing it that way because you have to allocate additional resources to store the buffer and cycle time for parsing etc.
[/quote]The time it takes to parse incoming data is negligible compared to a blocking call to recv.

[quote author=Eibro[yL] link=board=17;threadid=8140;start=0#msg75270 date=1092345729]
The time it takes to parse incoming data is negligible compared to a blocking call to recv.
[/quote]

If you are using event based async sockets like i am when data becomes available the processing thread is awakened from an efficient wait state.

The logic i am using means the data is already available on the network stack so the blocking is only for a very small inmeasureable time, it simply rewakens my thread for the next data fragment i think maybe you are confusing this situation with non asyc blocking sockets.

The system i use there is no delay no wasted processor cycles doing superflous parsing just efficient kernel based waitstates.

Also we were not talking about *times* we were talking about efficiency in terms of resources etc.

[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75269 date=1092345177]
First response i am just providing a basic framework which does not cover all eventualities otherwise i would be here all day, also im not going to write someones code for them, basic checks and such and standard programming practise, also if he has any specific questions i would be only to pleased to provide more information with a pm or response here.

If you feel the need to elaborate in more detail or provide some source code for him be my guest otherwise then i suggest you allow him to work the finer details for himself.
[/quote]

If you're going to tell him about your solution, don't make it look easier than it is. If you do, all that is going to happen is he implements the simple solution you described, and it doesn't work. Considering that this whole question was about handling the situation when b.net stuffs together packets and you have to parse out the right pieces, giving him an answer that doesn't correctly split up packets is bad. Giving a wrong answer is worse than giving no answer at all you know...

And no, I don't feel like providing source code, but I do feel like pointing out the things that are important for him to think of when writing his own source code.


[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75269 date=1092345177]
Just as a note the complete message is guarenteed delivery as this is tcp/ip i.e send/acknowlege protocol if the entrire packet sent from bnet is not completley received then it will not be passed on from the network subsystem ^^ :)
[/quote]

That's not correct. It will be passed on in pieces from the network subsystem. Pieces will not be passed on in the wrong order, and if you read data, you'll eventually get all the pieces, but there's no guaranteed entire packet at once delivery in tcp/ip.


[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75269 date=1092345177]
Considering the sizes of normal event messages in chat im assuming bnet would send an entire message at once rather splitting it up which would mean guarenteed delivery, or at the very least it would send a complete header, and my logic handles both of these conditions with ease.
[/quote]

As your previous point was incorrect, even though bnet might send an entire message at once, or a complete header, you may not receive a whole header at once from winsock.


[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75269 date=1092345177]
Ps. Maybe it would be more helpful if you make a contribution to the original question rather than just critising what i say.
[/quote]

I like to let people think for themselves. I point out the problems and what they have to think about, and then I let them solve the problems. If they get stuck, I hint more. I don't like to write people's bots for them.


[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75269 date=1092345177]
Also forgot last point it;s actually less efficient doing it that way because you have to allocate additional resources to store the buffer and cycle time for parsing etc.
[/quote]

It's actually more efficient doing it that way, because there will be fewer API calls. It's true that you'll need additional resources to store the buffer, but if you don't provide the buffer, winsock will have to buffer the data itself anyway, so it's just moving the same amount of resources to a different place. About the cycle time for parsing, I really don't see what you mean. You're parsing the packet and the length either way.

[quote author=Adron link=board=17;threadid=8140;start=0#msg75297 date=1092362479]
If you're going to tell him about your solution, don't make it look easier than it is. If you do, all that is going to happen is he implements the simple solution you described, and it doesn't work. Considering that this whole question was about handling the situation when b.net stuffs together packets and you have to parse out the right pieces, giving him an answer that doesn't correctly split up packets is bad. Giving a wrong answer is worse than giving no answer at all you know...
[/quote]

And who exactly said it was a solution? did you even read my post?, i said a basic framework not a solution i suggest you read the original post before replying next time.

A basic framework in no way contitutes a complete solution and i never stated that.

I imagine if every first reply to a thread on this forum provided complete solutions first time there would'nt be much activity no?.

I was attempting to try and guide that is all plain and simple i never intended to give a complete solution just an idea of what i try and do at a basic level.

Instead of bashing people who are trying to help maybe you should counsider contributing first?.

And once again as i said in my previous posts ( which you must have failed to read by what you have just written ) that if he needs any further assistance i would be pleased to help, so what is exactly wrong with trying to help?, what would you suggest? maybe go away for 3 hours write a complete soution then post//send to him? lol

[quote author=Adron link=board=17;threadid=8140;start=0#msg75297 date=1092362479]
That's not correct. It will be passed on in pieces from the network subsystem. Pieces will not be passed on in the wrong order, and if you read data, you'll eventually get all the pieces, but there's no guaranteed entire packet at once delivery in tcp/ip.
[/quote]

Yes once again did you read what i said ?
[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75269 date=1092345177]
if the entrire packet sent from bnet is not completley received then it will not be passed on from the network subsystem ^^
[/quote]

Which means yes the network layer can transport the data in fragments but if not all the fragments that comprise a transaction are received by the destination tcp/ip network then the subsystem will abort that transaction.

So if all fragments are received then the subsystem will generate the required system events which the application layer can handle, if not then that transaction is aborted!!.

Thats why tcp/ip has guarenteed delivery!, if This did not happen then you could send your data packet and you could not say for certain if the destination received it. That uncertainty does not exist for stream sockets, UDP does have that behaviour though.

[quote author=Adron link=board=17;threadid=8140;start=0#msg75297 date=1092362479]
As your previous point was incorrect, even though bnet might send an entire message at once, or a complete header, you may not receive a whole header at once from winsock.
[/quote]

Although true in theory yes a header could come in fragments my own code does handle this condition as i discribed, i simply continuing reading until both my header structure and data body are both complete.

But the likleyhood of receiving say 1/2 bytes and not being able to receive the rest of the 4 byte header in 1 network cycle is extremely low i would say probably in the 0.01% mark if not less.

[quote author=Adron link=board=17;threadid=8140;start=0#msg75297 date=1092362479]
I like to let people think for themselves. I point out the problems and what they have to think about, and then I let them solve the problems. If they get stuck, I hint more. I don't like to write people's bots for them.
[/quote]

But you are not trying to point out things for him instead you are trying to pick holes in my comments very pedantically.

[quote author=Adron link=board=17;threadid=8140;start=0#msg75297 date=1092362479]
It's actually more efficient doing it that way, because there will be fewer API calls. It's true that you'll need additional resources to store the buffer, but if you don't provide the buffer, winsock will have to buffer the data itself anyway, so it's just moving the same amount of resources to a different place. About the cycle time for parsing, I really don't see what you mean. You're parsing the packet and the length either way.
[/quote]

And you dont call api's when parsing ( and i mean the term api can apply to not only OS based functions but also C runtime functions ) for example strlen() ?.

Your may now say that system API's require more resources etc well one call to recv ( which uses code allready active in memory and an efficient low level API which would simply copy one buffer to another seems very low in cpu cycles because in the end if data is already on the network stack thats all it does copy the specified length of the network buffer to you local buffer which for single event messages is very small.

Also note ws32 dll is loaded into the address space of the application just the same way as the c runtime therefore the performance hit will be just the same if not less.

Compared with having to loop through a multi-packet clump parsing and extracting the relevent data.

I can bet you now my method requires less cpu cycles and leaves the system free to do other things, try it out if you dont believe me.

Ahem.

[code]
messageid = 0
messagelen = -1
buffer = new ByteBuffer()
while (socket.connected) {
buffer.append(socket.readdata())
if messagelen == -1 {
if buffer.position >= 4 {
hdr = buffer.read(4)
messageid = hdr[1]
messagelen = bytes2word(hdr[2],hdr[3])
}
}
if messagelen != -1 && buffer.position >= messagelen {
handle_message(messageid, buffer.read(messagelen))
messageid = -1
}
}
[/code]

That should work, AFAIK.

[quote author=$t0rm link=board=17;threadid=8140;start=15#msg75349 date=1092412169]
Ahem.

[code]
messageid = 0
messagelen = -1
buffer = new ByteBuffer()
while (socket.connected) {
buffer.append(socket.readdata())
if messagelen == -1 {
if buffer.position >= 4 {
hdr = buffer.read(4)
messageid = hdr[1]
messagelen = bytes2word(hdr[2],hdr[3])
}
}
if messagelen != -1 && buffer.position >= messagelen {
handle_message(messageid, buffer.read(messagelen))
messageid = -1
}
}
[/code]

That should work, AFAIK.
[/quote]

Ye that is the same kinda logic i was talking about, it's quite efficient doing it that way, although you would have to implement that code a in separate thread and use async event based sockets to get the most out of it :).

Actually thinking about it that is flawed in quite a few ways, what happends if you read in multiple events do you then have to parse them, if so that is completely Unnecessary.

When you do a read you can just set the number of bytes to read as the message length then you dont read multiple events in one cycle.

Getting the data into your own buffer is better than letting it stagnate in the TCP buffer.

[quote author=$t0rm link=board=17;threadid=8140;start=15#msg75393 date=1092434512]
Getting the data into your own buffer is better than letting it stagnate in the TCP buffer.
[/quote]

Eh? stagnate meaning what exactly?, it will just raise additional events within a very small amount of time how is that stagnating?

The kernel is generating these events we are talking about which has high system priority i hardly see how it's stagnating please elborate in detail.

Why let it waste your kernel's memory, when you can have it waste your own memory?

Some kernels leave data directly on the network card. If you leave your data there long enough, it may be overwritten. At that point, youeither have to have the remote host resend the data (which might not even be possible if your kernel has already acknowledged to the remote host that it's received the packets for the data being overwritten), or close the connection since the data is lost and thus the guaranteed reliability of TCP is broken.

Also, even if your kernel does copy the data to its own location (off the network card), it's better to not waste the kernal's memory.

[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75305 date=1092367903]
[quote author=Adron link=board=17;threadid=8140;start=0#msg75297 date=1092362479]
If you're going to tell him about your solution, don't make it look easier than it is. If you do, all that is going to happen is he implements the simple solution you described, and it doesn't work. Considering that this whole question was about handling the situation when b.net stuffs together packets and you have to parse out the right pieces, giving him an answer that doesn't correctly split up packets is bad. Giving a wrong answer is worse than giving no answer at all you know...
[/quote]

And who exactly said it was a solution? did you even read my post?, i said a basic framework not a solution i suggest you read the original post before replying next time.
[/quote]

Indeed, let's read the original post:

[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75201 date=1092314769]
Of course you could do what i do which is:-

(1) Do a recv on your socket using a length of HEADER_SIZE which is 0x04 on a bnchat connection.

(2) Copy the header buffer into a fixed length structure for easy access.

(3) The next recv event use a length of the size field in the header structure you read previously.

This works very well for me on bnchat and also saves you having to read a massive chunk of data then having to split it up with the possibility of incomplete data.

Of course this method assumes 2 things:-

(1) Your underlying socket paradigm allows you to read a data fragment then if there is still data left on the network stack raises additional events until that entire segment is read.

(2) The packet buffer you are using has sufficient space to accomodate a complete event message, which is not a problem with bnchat as the events are very small.
[/quote]

I can't see any other way to interpret this than that it is a step by step explanation of what he needs to do to have a framework for separating out packets correctly from the data received from b.net. I see nothing indicating that it's just intended as a "basic framework" (which I would still require to be correct instead of faulty) and no disclaimer saying "this is not a solution".



[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75305 date=1092367903]
A basic framework in no way contitutes a complete solution and i never stated that.

I was attempting to try and guide that is all plain and simple i never intended to give a complete solution just an idea of what i try and do at a basic level.
[/quote]

As I said above, there is no indication in your post that this is just food for thought and not a valid way of doing it.


[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75305 date=1092367903]
I imagine if every first reply to a thread on this forum provided complete solutions first time there would'nt be much activity no?.
[/quote]

Activity... Yes, I suppose posting non-working solutions on the forum is one way of generating activity.



[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75305 date=1092367903]
Instead of bashing people who are trying to help maybe you should counsider contributing first?.
[/quote]

I'm contributing by bashing out the people who spread lies and flawed solutions. Weeding out a bit.


[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75305 date=1092367903]
And once again as i said in my previous posts ( which you must have failed to read by what you have just written ) that if he needs any further assistance i would be pleased to help, so what is exactly wrong with trying to help?, what would you suggest? maybe go away for 3 hours write a complete soution then post//send to him? lol
[/quote]

I'd suggest always pointing out when you post incomplete or flawed solutions, so that it's clear that it's not supposed to work. It's really annoying to get a solution from someone, assume it has been tested and is going to work, go on to implement it, find that it doesn't work, then look at your code over and over for hours, trying to see where the difference is between what that guy said you were supposed to do and what your code does, before you give up and realize that that someone was just messing with you, making you waste your time.


[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75305 date=1092367903]
[quote author=Adron link=board=17;threadid=8140;start=0#msg75297 date=1092362479]
That's not correct. It will be passed on in pieces from the network subsystem. Pieces will not be passed on in the wrong order, and if you read data, you'll eventually get all the pieces, but there's no guaranteed entire packet at once delivery in tcp/ip.
[/quote]

Yes once again did you read what i said ?
[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75269 date=1092345177]
if the entrire packet sent from bnet is not completley received then it will not be passed on from the network subsystem ^^
[/quote]

Which means yes the network layer can transport the data in fragments but if not all the fragments that comprise a transaction are received by the destination tcp/ip network then the subsystem will abort that transaction.

So if all fragments are received then the subsystem will generate the required system events which the application layer can handle, if not then that transaction is aborted!!.

Thats why tcp/ip has guarenteed delivery!, if This did not happen then you could send your data packet and you could not say for certain if the destination received it. That uncertainty does not exist for stream sockets, UDP does have that behaviour though.
[/quote]

The transaction isn't aborted if all fragments aren't received at a certain time. It's delayed, waiting for the rest of the fragments. After some timeout I'm assuming the connection will be reset.

You said: "if the entrire packet sent from bnet is not completley received then it will not be passed on from the network subsystem". I say: Even if only the first two bytes of the packet sent from bnet have been received, the network subsystem will pass those two bytes on to the application.



[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75305 date=1092367903]
But the likleyhood of receiving say 1/2 bytes and not being able to receive the rest of the 4 byte header in 1 network cycle is extremely low i would say probably in the 0.01% mark if not less.
[/quote]

I guesstimated that each time you join a channel full of people, there'll be a 5% chance of getting only half a header.


[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75305 date=1092367903]
[quote author=Adron link=board=17;threadid=8140;start=0#msg75297 date=1092362479]
I like to let people think for themselves. I point out the problems and what they have to think about, and then I let them solve the problems. If they get stuck, I hint more. I don't like to write people's bots for them.
[/quote]

But you are not trying to point out things for him instead you are trying to pick holes in my comments very pedantically.
[/quote]

I started by pointing out things for him that you hadn't mentioned in your description of what he was supposed to do - that in addition to what you said, he also needs to handle incomplete packets in some way. From that, I've gone on to correct other incorrectnesses, as well as commenting on your comments.


[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75305 date=1092367903]
[quote author=Adron link=board=17;threadid=8140;start=0#msg75297 date=1092362479]
It's actually more efficient doing it that way, because there will be fewer API calls. It's true that you'll need additional resources to store the buffer, but if you don't provide the buffer, winsock will have to buffer the data itself anyway, so it's just moving the same amount of resources to a different place. About the cycle time for parsing, I really don't see what you mean. You're parsing the packet and the length either way.
[/quote]

And you dont call api's when parsing ( and i mean the term api can apply to not only OS based functions but also C runtime functions ) for example strlen() ?.
[/quote]

Of course I don't call strlen when parsing out a packet from the b.net stream. There's no reason whatsoever to call strlen for that. You have the length in the header!


[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75305 date=1092367903]
Your may now say that system API's require more resources etc well one call to recv ( which uses code allready active in memory and an efficient low level API which would simply copy one buffer to another seems very low in cpu cycles because in the end if data is already on the network stack thats all it does copy the specified length of the network buffer to you local buffer which for single event messages is very small.

Also note ws32 dll is loaded into the address space of the application just the same way as the c runtime therefore the performance hit will be just the same if not less.
[/quote]

I'd like to point out that it's not very low in cycles at all. recv calls WSARecv, which calls WSPRecv, which calls NtDeviceIoControlFile, which calls into kernel code. This takes a whole lot of cycles. Many many many more than a simple memmove. Therefore the performance hit for recv will be much larger than that for most C runtime library functions.


[quote author=OnlyMeat link=board=17;threadid=8140;start=0#msg75305 date=1092367903]
Compared with having to loop through a multi-packet clump parsing and extracting the relevent data.

I can bet you now my method requires less cpu cycles and leaves the system free to do other things, try it out if you dont believe me.
[/quote]

I can bet you now that calling recv with a large buffer and splitting up the pieces yourself requires less cpu cycles and leaves the system free to do other things. If you have a suggestion for how to test it, I'd love to try it out.

Wow that took me like a while to read and I got a headache reading it, but you made some very good points, OnlyMeat is a no good flamer/basher who makes fun of others on the forum.

Well, I ended up using The-Fool gave me after tweaking it a little I made it work for my bot. I have found nothing you people have posted useful (Maybe I shouldn't just skim-read....), and storm, why did you paste the C code to it?

I pasted working psuedocode which 100% totally completely solved this (you'd have to translate it to VB, thats it)

...but of course, no one ever listens to me, anyway. Your loss.

I know too little of C to translate and I am too lazy to see if there is a program to do it. On the finishing note, I am Lazy.

[code]
Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long)

Static sBuffer As String
Dim strTmp As String
Dim intMessageID As Integer
Dim intMessageLen As Integer

Winsock1.GetData sTmp, vbString
sBuffer = sBuffer & sTmp

While LenB(sBuffer) > 0
If Len(sBuffer) >= 4 Then
' Get header information.
intMessageID = Asc(Mid$(sBuffer, 2, 1))
intMessageLen = Bytes2Word(Mid$(sBuffer, 3, 2))

' Check to see if it's a complete packet.
If intMessageLen <= Len(sBuffer) Then
HandlePacket intMessageID, Mid$(sBuffer, 5, intMessageLen - 4)

' Remove handled packet from buffer
sBuffer = Right$(sBuffer, Len(sBuffer) - intMessageLen)
Else
' Incomplete packet.
Exit Do
End If
Else
' Incomplete header.
Exit Do
End If
Wend

End Sub
[/code]

[quote author=Kk)Blaze(kK link=board=17;threadid=8140;start=15#msg75609 date=1092591601]
I know too little of C to translate and I am too lazy to see if there is a program to do it. On the finishing note, I am Lazy.
[/quote]

On a side note, your [s]attiture[/s] attitude fucking blows.

[quote author=Kk)Blaze(kK link=board=17;threadid=8140;start=15#msg75609 date=1092591601]
I know too little of C to translate and I am too lazy to see if there is a program to do it. On the finishing note, I am Lazy.
[/quote]

You apparently don't read too well. $t0rm posted PSEUDOCODE, that is, code that does not belong to any particular language, but is intended to demonstrate the steps necessary to solve the problem. There was no translation to or from C required.

[quote author=Kk)Blaze(kK link=board=17;threadid=8140;start=15#msg75609 date=1092591601]
I know too little of C to translate and I am too lazy to see if there is a program to do it. On the finishing note, I am Lazy.
[/quote]

i fucking hate you and i'm never helping you again.

it's easy as hell to read, even for the vb "programmer" that you are. if you'd rather copy someone elses code and then get bitched off the forum cause everyone hates you, that's your business.

good bye.

[quote author=$t0rm link=board=17;threadid=8140;start=15#msg75597 date=1092587186]
I pasted working psuedocode which 100% totally completely solved this (you'd have to translate it to VB, thats it)

...but of course, no one ever listens to me, anyway. Your loss.
[/quote]

I was in the middle of something else, otherwise I would've commented that you should loop parsing the buffer in case there's more than one message received in the same readdata.

Whoops, knew I forgot something...
[code]
messageid = 0
messagelen = -1
buffer = new ByteBuffer()
while (socket.connected) {
buffer.append(socket.readdata())
while messagelen == -1 {
if buffer.position >= 4 {
hdr = buffer.read(4)
messageid = hdr[1]
messagelen = bytes2word(hdr[2],hdr[3])
}
}
if messagelen != -1 && buffer.position >= messagelen {
handle_message(messageid, buffer.read(messagelen))
messageid = -1
}
}[/code]

$torm is that java or C? somtimes they look exactly the same...meh i use java cause im lazy and like using premade classes

psuedocode.......................

[quote author=$t0rm link=board=17;threadid=8140;start=15#msg75669 date=1092616247]
Whoops, knew I forgot something...
[code]
messageid = 0
messagelen = -1
buffer = new ByteBuffer()
while (socket.connected) {
buffer.append(socket.readdata())
while messagelen == -1 {
if buffer.position >= 4 {
hdr = buffer.read(4)
messageid = hdr[1]
messagelen = bytes2word(hdr[2],hdr[3])
}
}
if messagelen != -1 && buffer.position >= messagelen {
handle_message(messageid, buffer.read(messagelen))
messageid = -1
}
}[/code]
[/quote]

Umm, not all that much better? Needs to loop the whole read?

How about this for solving that?

[code]
messageid = 0
messagelen = -1
buffer = new ByteBuffer()
while (socket.connected) {
buffer.append(socket.readdata())
do {
if messagelen == -1 {
if buffer.position >= 4 {
hdr = buffer.read(4)
messageid = hdr[1]
messagelen = bytes2word(hdr[2],hdr[3])
}
}
if messagelen != -1 && buffer.position >= messagelen {
handle_message(messageid, buffer.read(messagelen))
messageid = -1
}
} while messageid == -1 && buffer.position >= 4
}
[/code]

bah, didn't look at it close enough; thought the while encompassed the second part.

[quote author=$t0rm link=board=17;threadid=8140;start=15#msg75645 date=1092606246]
[quote author=Kk)Blaze(kK link=board=17;threadid=8140;start=15#msg75609 date=1092591601]
I know too little of C to translate and I am too lazy to see if there is a program to do it. On the finishing note, I am Lazy.
[/quote]

i fucking hate you and i'm never helping you again.

it's easy as hell to read, even for the vb "programmer" that you are. if you'd rather copy someone elses code and then get bitched off the forum cause everyone hates you, that's your business.

good bye.
[/quote]

If I can't read why didn't you read this?


[quote author=Kk)Blaze(kK link=board=17;threadid=8140;start=15#msg75578 date=1092558171]
(Maybe I shouldn't just skim-read....)
[/quote]

[quote author=Kk)Blaze(kK link=board=17;threadid=8140;start=15#msg75609 date=1092591601]
I know too little of C to translate and I am too lazy to see if there is a program to do it. On the finishing note, I am Lazy.
[/quote]

I took time out of my day and thought about that and typed it out for you. I could've been doing something else, but I decided to help you because you were new. Won't make that mistake again...