2010/1/15 Jon Hylands <jon at huv.com>:
> On Fri, 15 Jan 2010 01:00:54 +0100, Göran Krampe <goran at krampe.se>
> wrote:
>
>>...but thanks for digging in the SocketStream code! It was quite a while
>>since I wrote it :)
>>
>>While we are at it we should improve the primitive for searching in
>>String/ByteArrays to include at stopAt: argument. This would increase
>>speed and simplify the horribly tricky logic in the upTo: family of
>>methods in SocketStream.
>
> It would be nice if, for whoever is doing this, you could include some
> kind of switch to indicate how the socket is being used. Most people
> retrieve large files and images over sockets, but in my robotics work
> I use them for sending and receiving very small commands, on the order
> of 10-20 bytes typically.
>
My proposal is following logic:

1. read only data available (but not more 100kb), then search for pattern
2. repeat 1 until pattern is found

So, if remote end sends a small 10-20 bytes packets, it will read them
and then search immediately.
This is, of course, assuming that remote end not sending packets too
fast, so there are some gaps in #isDataAvailable.

Alternatively, we could include
upto: sequence checkEach: nBytes

so, you could pass own constant, which you think is more appropriate
for your data.

> From the comment in #upTo:
>
> "Another measure is that this implementation is greedy and will load
> data into the buffer until there is nothing more available, or it has
> loaded 100kb - and not until then we search the buffer."
>
> I need an implementation of #upTo: that is much more direct - I ended
> up writing my own for now, that uses a much smaller constant.
>
> Thanks,
> Jon
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.