🚀 go-pugleaf

First of all, thanks a lot for your help.

I don't know where the 370 bytes come from, i send 2 packets of 20 bytes.
Maybe the sockets put some header in it too.?
Anyways, i am gonna follow up your advice and first compose all packets to
be send before sending them.
The delimiter idear is not a good one in my case becouse i use compressed
data, a scenario could be that the compressed data looks like a delimiter.



> > I try to send information from one bb app to another using :
> >
> >  int r = sendto(SOCKET,bytes,length,0,(sockaddr
> *)&to,sizeof(sockaddr_in));
>
> How many bytes are you actually sending each time you call sendto()?
>
> > I send 3 packets after eachother.
> > The first packet is received corectly, the second one
> > is 370 bytes instead of the 20 bytes send.
> > The third one isn't received at all.
>
> Did you actually send 370+ bytes to begin with?  If so, then what you
> describe is perfectly normal socket behavior.  Multiple packets can (and
> usually are) merged together during transmission, and a single packet can
> (and usually is) split into multiple transmissions.  Your code has to be
> able to handle all three situations (receiving individual packets as-is,
> receiving merged packets , and receiving split packets).
>
> > If i place a Sleep(200); between the send calls, i do receive
> > the packets correctly.
>
> That just goes to show that your packets are likely being merged together
> and your receiving code is not set up to handle that situation.
>
> > Is anyone familliar with this problem and knows a better solution
> > than Sleep(200); ???
>
> Re-design your code to handle the packets properly in the first place.
The
> best way is to continuously place everything you receive into a buffer,
and
> then process your packets from the buffer only when they are completely
> available.  How you determine when a given packet is completely available
> depends on the actual layout of your packets.  Unless all of your packets
> are the same fixed length each time, then you have a couple of options:
>
> 1) the best thing to do is to place a fixed-length header at the beginning
> of each packet which includes a field to specify the size of the remaining
> variable-length packet data.  You can then look at the packet header to
know
> if the remaining packet data is available yet.
>
> 2) place a unique delimiter between your packets, using a single byte or a
> byte sequence that is guaranteed to never appear inside your packet data.
> Then you can look for that delimiter when checking your buffer for
complete
> packets.
>
>
> Gambit
>
>