SocketStream>>atEnd

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

SocketStream>>atEnd

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

Reply | Threaded
Open this post in threaded view
|

Re: SocketStream>>atEnd

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

Reply | Threaded
Open this post in threaded view
|

Re: Re: SocketStream>>atEnd

Göran Krampe
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


Reply | Threaded
Open this post in threaded view
|

Re: Re: SocketStream>>atEnd

Jon Hylands
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


Reply | Threaded
Open this post in threaded view
|

Re: Re: SocketStream>>atEnd

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