Smalltalk › Squeak › Squeak - Dev

SocketStream>>atEnd

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Igor Stasenko

SocketStream>>atEnd

Hello guys,

today, by examining closely the #atEnd implementation , i came to
conclision that is can be made as simple as:

atEnd
^ self isDataAvailable not

Because, take a close look at old implementation:
atEnd
self isInBufferEmpty ifFalse: [^false]. ----***---
^self isConnected not
and: [self isDataAvailable not]

and:
isDataAvailable

self isInBufferEmpty ifFalse: [^true]. ---***---
^socket dataAvailable
ifFalse: [false]
ifTrue: [self receiveDataIfAvailable; isDataAvailable]

a Socket>>dataAvailable answers false on closed or invalid socket. You
can check it quite simply:

(SocketStream openConnectionToHostNamed: 'google.com' port: 80)
socket closeAndDestroy dataAvailable
(SocketStream openConnectionToHostNamed: 'google.com' port: 80) close
socket dataAvailable
Socket new dataAvailable
=> all 3 answer false

Therefore, a complex logic in #atEnd, could be simplified.

Please, try to find a flaw in my conclusions. I think there's not. But
2 (or more) heads always better than 1.

--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko

Re: SocketStream>>atEnd

It appears that im wrong. sorry for disturbing :)

2010/1/15 Igor Stasenko <[hidden email]>:

> Hello guys,
>
> today, by examining closely the #atEnd implementation , i came to
> conclision that is can be made as simple as:
>
> atEnd
> ^ self isDataAvailable not
>
>
> Because, take a close look at old implementation:
> atEnd
> self isInBufferEmpty ifFalse: [^false]. ----***---
> ^self isConnected not
> and: [self isDataAvailable not]
>
> and:
> isDataAvailable
>
> self isInBufferEmpty ifFalse: [^true]. ---***---
> ^socket dataAvailable
> ifFalse: [false]
> ifTrue: [self receiveDataIfAvailable; isDataAvailable]
>
>
> a Socket>>dataAvailable answers false on closed or invalid socket. You
> can check it quite simply:
>
> (SocketStream openConnectionToHostNamed: 'google.com' port: 80)
> socket closeAndDestroy dataAvailable
> (SocketStream openConnectionToHostNamed: 'google.com' port: 80) close
> socket dataAvailable
> Socket new dataAvailable
> => all 3 answer false
>
> Therefore, a complex logic in #atEnd, could be simplified.
>
> Please, try to find a flaw in my conclusions. I think there's not. But
> 2 (or more) heads always better than 1.
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

--
Best regards,
Igor Stasenko AKA sig.

Göran Krampe

Re: Re: SocketStream>>atEnd

Igor Stasenko wrote:
> It appears that im wrong. sorry for disturbing :)

...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.

The reason for the trickiness is the fact that the search primitive
always searches to the very end of the buffer (there is no stopAt:
parameter) AND the buffer can of course include old data after the
current end marker in which we may find "false hits".

I remember the pain in writing that code...

regards, Göran

Jon Hylands

Re: Re: SocketStream>>atEnd

On Fri, 15 Jan 2010 01:00:54 +0100, Göran Krampe <[hidden email]>
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.

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

Igor Stasenko

Re: Re: SocketStream>>atEnd

2010/1/15 Jon Hylands <[hidden email]>:

> On Fri, 15 Jan 2010 01:00:54 +0100, Göran Krampe <[hidden email]>
> 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.