gen.TcpHandle Question about ergo

[DustOak]

This result is completely different from the result returned in the case comment.

[halturin]

If I do understand your question correctly... The main reason for returning left, await values is that you might receive a packet with the tail of your logical struct and the header of the next one. In this case, gen.TCP will append the tail data to the packet buffer and invoke HandlePacket with the packet containing the full logical struct while keeping the head data for the next packet.

[DustOak]

i get it
thank you

[DustOak]

I send a slice -> [3 217 0 0 26 0 0 0 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90]

I send divided into two this slice

3 seconds at intervals

e.g.
dial.Write(slice[:4])
time.Sleep(time.Second * 3)
dial.Write(slice[4:])

but when when call HandlePacket first call
This branch will be triggered:
plen := len(packet) if plen < headLength { log.Errorf("packet too short %d", plen) return plen, headLength, gen.TCPHandlerStatusOK }
when I send slice[4:]. second call HandlePacket
packet data is -> [26 0 0 0 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90]

where is my first data?

[halturin]

not sure if I follow your example. could you please share your HandlePacket code and what you expected to see

[DustOak]

func (this *handle) HandlePacket(process *gen.TCPHandlerProcess, packet []byte, conn *gen.TCPConnection) (int, int, gen.TCPHandlerStatus) {
plen := len(packet)
if plen < headLength {
log.Errorf("packet too short %d", plen)
return plen, headLength, gen.TCPHandlerStatusOK
}
log.Infof("pid %s handle packet: %v", process.Self(), packet)
head := make([]byte, headLength)
copy(head, packet)
code := binary.LittleEndian.Uint32(head)
length := binary.LittleEndian.Uint32(head[4:])
if uint32(plen-headLength) < length {
log.Errorf("packet too short,code is %d cur packet length %d need length %d", code, plen-headLength, length)
return plen - headLength, int(length), gen.TCPHandlerStatusOK
}
body := make([]byte, length)
copy(body, packet[headLength:])
log.Infof("pid %s code: %d length :%d body %s", process.Self(), code, length, string(body))
return plen - headLength - int(length), headLength, gen.TCPHandlerStatusOK
}

I think when packet is not enough（8byte）， I will wait next call At this point, I can get the complete data.

But it not，it have next data but first data is lose

[DustOak]

e.g
I send a slice -> [3 217 0 0 26 0 0 0 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90]

I send divided into two this slice

3 seconds at intervals

code:
dial.Write(slice[:4])
time.Sleep(time.Second * 3)
dial.Write(slice[4:])

I know that returning a "packet too short" error on the first call

But on the second call, you must receive the complete data after being sent twice.

It is -> [3 217 0 0 26 0 0 0 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90]

but I receive [26 0 0 0 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90]

I lose [3 217 0 0]

That is the data sent for the first time.

[halturin]

You lose the first 4 bytes because of a timeout of socket reading which is 3 seconds by default. To see that, you can add a method HandleTimeout to your object *handle. The buffer is clearing on this event, that's where you lost these bytes. To fix your example just decrease your sending timeout.

I'm thinking of fixing it by keeping the data in the buffer even timeout is happening.

[DustOak]

Thank you. but I have a new question

#153

[halturin]

done in v2.2.3