headers
Michael Roberts | 1 Sep 2010 01:17
Picon

Re: Sockets in Pharo CollaborActive Book

Hi,

it just so happens I wrote that section on the colab wiki 1) primarily
to play around with the wiki engine 2) I was debugging Magma socket
issues and I could not find decent cookbook / snippets to illustrate
some simple examples and how to test it outside of Pharo itself.  I
just thought as an exercise i would write it down....

so in response to this entire thread, huh?

The example

>
> | server client |
> server := Socket newTCP.
> server listenOn: 12345 backlogSize: 4.
> server waitForConnectionFor: 600.
> client := server accept.
> client receiveData

is only server side. If you follow the sections, you can see I used
netcat as the client and illustrated some simple cmd line debugging
techniques.  the code above whilst it could of course contains bugs
and not use the right API is consistent in what it tries to do.

>so is this where we want to direct people first?

well, no, but sockets are fundamental and should be explained.  I had
only imagined it the seed for something bigger. the colab book will
not expand unless people start somewhere. It is a work in progress as
(Continue reading)

Permalink | Reply |
headers
Sean P. DeNigris | 1 Sep 2010 04:41
Gravatar

Re: Sockets in Pharo CollaborActive Book


Michael Roberts-2 wrote:
> 
> The example
> <snip>
> is only server side. If you follow the sections, you can see I used
> netcat as the client and illustrated some simple cmd line debugging
> techniques.  the code above whilst it could of course contains bugs
> and not use the right API is consistent in what it tries to do.
> 
Ah, okay.  Now I got it.  The client temporary variable, along with the fact
that this snippet is a section to itself confused me and I didn't keep
reading.

>so is this where we want to direct people first?

Michael Roberts-2 wrote:
> 
> well, no, but sockets are fundamental and should be explained.  I had
> only imagined it the seed for something bigger. the colab book will
> not expand unless people start somewhere. It is a work in progress as
> well, remember that...
> 
Cool, I appreciate you getting the ball rolling - I am trying to push it
further! (and I don't know too much about sockets)

Sean
--

-- 
View this message in context: http://forum.world.st/Sockets-in-Pharo-CollaborActive-Book-tp2399361p2402542.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
(Continue reading)

Permalink | Reply |
headers
Schwab,Wilhelm K | 1 Sep 2010 05:59
Picon
Favicon

Re: Sockets in Pharo CollaborActive Book

The deeper question is whether we want to document how things are, or they they *should be* - which is VERY
much different from the eventless and timeout ridden design that we have now.  It desperately needs to be redesigned.

________________________________________
From: pharo-project-bounces@...
[pharo-project-bounces@...] On Behalf Of Sean P.
DeNigris [sean@...]
Sent: Tuesday, August 31, 2010 10:41 PM
To: pharo-project@...
Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book

Michael Roberts-2 wrote:
>
> The example
> <snip>
> is only server side. If you follow the sections, you can see I used
> netcat as the client and illustrated some simple cmd line debugging
> techniques.  the code above whilst it could of course contains bugs
> and not use the right API is consistent in what it tries to do.
>
Ah, okay.  Now I got it.  The client temporary variable, along with the fact
that this snippet is a section to itself confused me and I didn't keep
reading.

>so is this where we want to direct people first?

Michael Roberts-2 wrote:
>
> well, no, but sockets are fundamental and should be explained.  I had
> only imagined it the seed for something bigger. the colab book will
(Continue reading)

Permalink | Reply |
headers
Miguel Enrique Cobá Martínez | 1 Sep 2010 06:10
Picon
Gravatar

Re: Sockets in Pharo CollaborActive Book

El mar, 31-08-2010 a las 23:59 -0400, Schwab,Wilhelm K escribió:
> The deeper question is whether we want to document how things are, or they they *should be* - which is VERY
much different from the eventless and timeout ridden design that we have now.  It desperately needs to be redesigned.
> 

Maybe it needs someone to lead the effort. Why don't you begin with
this? It appears that you know a lot about sockets. Certainly the pharo
community will be grateful of your efforts.
But saying again and again that sockets sucks doesn't fix it for
anybody, including you.

So, as Stef says, less saying, more coding. Very respectfully, show us
your code :)

Cheers

> 
> 
> 
> ________________________________________
> From: pharo-project-bounces <at> lists.gforge.inria.fr
[pharo-project-bounces <at> lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean <at> clipperadams.com]
> Sent: Tuesday, August 31, 2010 10:41 PM
> To: pharo-project <at> lists.gforge.inria.fr
> Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book
> 
> Michael Roberts-2 wrote:
> >
> > The example
> > <snip>
(Continue reading)

Permalink | Reply |
headers
Schwab,Wilhelm K | 1 Sep 2010 07:37
Picon
Favicon

Re: Sockets in Pharo CollaborActive Book

I am certainly willing to help with the work, and while I am by no means an expert on sockets, I have seen some
good code.  As we stand now, it is all but impossible to do things correctly; that will become clear by
contrast, but only if people are willing to challenge their ideas.  Timeouts are bad (unless provided by
helper methods so they are explicitly requested); errors are helpful (silent failures are toxic);
events are essential.

It sounds like there are at least four of us who have strong interest in getting this right.  We probably
should have some discussion here, then describe a plan on the wiki and finally start coding.

Bill

________________________________________
From: pharo-project-bounces@...
[pharo-project-bounces <at> lists.gforge.inria.fr] On Behalf Of Miguel Enrique Cobá Martínez [miguel.coba@...]
Sent: Wednesday, September 01, 2010 12:10 AM
To: Pharo-project@...
Subject: Re: [Pharo-project] Sockets in Pharo CollaborActive Book

El mar, 31-08-2010 a las 23:59 -0400, Schwab,Wilhelm K escribió:
> The deeper question is whether we want to document how things are, or they they *should be* - which is VERY
much different from the eventless and timeout ridden design that we have now.  It desperately needs to be redesigned.
>

Maybe it needs someone to lead the effort. Why don't you begin with
this? It appears that you know a lot about sockets. Certainly the pharo
community will be grateful of your efforts.
But saying again and again that sockets sucks doesn't fix it for
anybody, including you.

So, as Stef says, less saying, more coding. Very respectfully, show us
(Continue reading)

Permalink | Reply |
headers
Noury Bouraqadi | 4 Sep 2010 11:31
Picon

Re: Sockets in Pharo CollaborActive Book

Hi Bill,

On 1 sept. 2010, at 05:59, Schwab,Wilhelm K wrote:

> The deeper question is whether we want to document how things are, or they they *should be* - which is VERY
much different from the eventless and timeout ridden design that we have now.  It desperately needs to be redesigned.
> 
I agree that the current status of the networking libraries is horrible. 
But, to learn the current status and think of the alternatives, I felt the need to understand how thinks work now.

As Stéf said, Luc and I started the Ocean project.
Thanks you Bill and to Guille for your proposal to help.
It's a pitty that you don't attend to the ESUG conf (Your names are not on the registrations list) otherwise
we could discuss this better. Cause Luc and I will give a short presentation describing the current status
of Ocean and where it is headed.
Now, we need to think how to split the project in order to have other contributions.

Note BTW, our goal is to have a low-level Pharo wrappers of the networking facilities of the OS.
We started using Alien to avoid using a plugin and ease portability.
Once we get this low-level layer, we'll go on and use it in an OOP middleware like rST and UbiquiTalk.
Which is after all, the right level to work with since we want to deal with objects and message sends.
A direct use of Sockets isn't really OO most of the time. 

Noury
Permalink | Reply |
headers
Schwab,Wilhelm K | 4 Sep 2010 17:59
Picon
Favicon

Re: Sockets in Pharo CollaborActive Book

Noury,

First, please don't assume that you have to change course just because we offered to help.  If you are close to
having a major improvement, then it might be best to just power through it.  If there are things holding you
up, we might be able to help there.

Using Alien concerns me a little, as the last time I checked, it was not available on Linux??  Failure to
support Linux would be a complete show-stopper for me.  Regardless, I would like to see your code as I have
read some comments suggesting that Alien is cumbersome to use; you might show me that all is well.  My
interest in Alien is primarily to support callbacks for numerical analysis.  So far, I have been adding
functions to a shared library, which is easy enough, ultimately translates formulas using C++ (which is
better at it than Smalltalk), likely makes things go faster than they would with Smalltalk in the loop, but
is far from elegant.  Until Alien exists on Linux, it does not exist :(

Back to sockets, if the current situation were to stand, for whatever reason, I would consider tackling the
problem using a plugin to get OS threads, and use them to achieve the non-blocking operation that is
essential for interactive software.  In short, everything blocks its calling Smalltalk Process;
nothing blocks the entire image.  Hopefully you recognize that a server listening with timeouts is
hideous design; just start and stop the server as needed, and it should be harmless to the image.  If the
server is not harmless to the image, it needs to be fixed.  Clients having timeouts isn't much better.  If you
want to add helper methods with timeouts, who am I to tell others what to do, but we must not force timeouts on
clients because there is no correct answer to how long something should wait, so we should not look for one. 
What we should do is make sure that we never block the entire image, and let people make their own decisions.

Why would I consider a plugin?  In large part because there are hints that I would find examples to follow, and
because OpenSSL has a very cumbersome non-blocking interface, at least that was my impression of it.  A
plugin that I would write would hopefully support TCP and OpenSSL sockets, and hopefully IrDA.  Running
those things on OS threads and signaling semaphores in the image is likely to be simpler than working out
the details of non-blocking calls in the separate worlds - I think.  I can understand why you are not
thrilled about creating a plugin.
(Continue reading)

Permalink | Reply |
headers
Schwab,Wilhelm K | 5 Sep 2010 03:22
Picon
Favicon

Re: Sockets in Pharo CollaborActive Book

Noury,

I was struggling a little with a stream for serial ports, and thought you might have tackled the problem of a
generating stream (one that can grow in the background).  Now that I type that, maybe Nile has the answer?? 

Re Ocean, I grabbed a .mcz from SqueakSource and simply browsed the main package.  Some comments: 

(1) no socket stream :(   Streams are really slick things, and good read and write stream semantics should
exist for sockets.  FWIW, Dolphin separates the socket read and write streams, and we might do well to
follow their lead.

(2) ByteArray>>asAlien loops over the bytes.  Do all the bounds checking you want up front (once) and then
use memcpy() or something to actually transfer the data.  It recently came to my attention that Squeak has
no formalized approach to access, copy and move external memory; Pharo needs to offer that, and this is a
good place to start.

(3) You are planning to attack ipv4 vs. 6 with polymorphism - good call!!

(4) OCNTcpSocket>>send: sizes a buffer to match the data provided to it.  I'm not sure I like that.  You might
consider renaming your current #send: to #basicSend: and adding something like

send:blob
| in |
in := blob readStream.
[ in atEnd ] whileFalse:[
   self basicSend:( in nextAvailable:self alienDataBufferSize ).
].

so that a fixed buffer (which will have to be allocated when the socket is opened) is used to send large blobs
in buffer-sized chunks.  Better still would be to use array indexing to cope with the blob in pieces but in
(Continue reading)

Permalink | Reply |
headers
Noury Bouraqadi | 8 Sep 2010 19:40
Picon

Re: Sockets in Pharo CollaborActive Book


On 5 sept. 2010, at 03:22, Schwab,Wilhelm K wrote:

> Noury,
> 
> I was struggling a little with a stream for serial ports, and thought you might have tackled the problem of a
generating stream (one that can grow in the background).  Now that I type that, maybe Nile has the answer?? 
> 
> Re Ocean, I grabbed a .mcz from SqueakSource and simply browsed the main package.  Some comments: 
> 
> (1) no socket stream :(   Streams are really slick things, and good read and write stream semantics should
exist for sockets.  FWIW, Dolphin separates the socket read and write streams, and we might do well to
follow their lead.
> 
Not yet ;-)
So far, we want to have a clean socket. And then we'll rebuild a SocketStream on top of it.

> (2) ByteArray>>asAlien loops over the bytes.  Do all the bounds checking you want up front (once) and then
use memcpy() or something to actually transfer the data.  It recently came to my attention that Squeak has
no formalized approach to access, copy and move external memory; Pharo needs to offer that, and this is a
good place to start.
> 
Thanks for the hint.

> (3) You are planning to attack ipv4 vs. 6 with polymorphism - good call!!
> 
Yes. One reason behind doing Ocean is that we found existing library too dirty to improve.
So, we try to have a well designed tested library.

> (4) OCNTcpSocket>>send: sizes a buffer to match the data provided to it.  I'm not sure I like that.  You might
(Continue reading)

Permalink | Reply |
headers
Michael Roberts | 1 Sep 2010 09:03
Picon

Re: Sockets in Pharo CollaborActive Book

>>
> Cool, I appreciate you getting the ball rolling - I am trying to push it
> further! (and I don't know too much about sockets)

no worries. I have found this guide really useful:   http://beej.us/guide/bgnet/

Even if you don't read C, there are lots of comments throughout.

cheers
Mike
Permalink | Reply |
headers
Stéphane Ducasse | 1 Sep 2010 10:05
Picon
Picon
Favicon
Gravatar

Re: Sockets in Pharo CollaborActive Book

would be cool to get inspired and produce material for smalltalkers.

On Sep 1, 2010, at 9:03 AM, Michael Roberts wrote:

>>> 
>> Cool, I appreciate you getting the ball rolling - I am trying to push it
>> further! (and I don't know too much about sockets)
> 
> no worries. I have found this guide really useful:   http://beej.us/guide/bgnet/
> 
> Even if you don't read C, there are lots of comments throughout.
> 
> cheers
> Mike
> 
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@...
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Permalink | Reply |
headers
Stéphane Ducasse | 1 Sep 2010 10:02
Picon
Picon
Favicon
Gravatar

Re: Sockets in Pharo CollaborActive Book

please continue :)

On Sep 1, 2010, at 1:17 AM, Michael Roberts wrote:

> Hi,
> 
> it just so happens I wrote that section on the colab wiki 1) primarily
> to play around with the wiki engine 2) I was debugging Magma socket
> issues and I could not find decent cookbook / snippets to illustrate
> some simple examples and how to test it outside of Pharo itself.  I
> just thought as an exercise i would write it down....
> 
> so in response to this entire thread, huh?
> 
> The example
> 
>> 
>> | server client |
>> server := Socket newTCP.
>> server listenOn: 12345 backlogSize: 4.
>> server waitForConnectionFor: 600.
>> client := server accept.
>> client receiveData
> 
> is only server side. If you follow the sections, you can see I used
> netcat as the client and illustrated some simple cmd line debugging
> techniques.  the code above whilst it could of course contains bugs
> and not use the right API is consistent in what it tries to do.
> 
>> so is this where we want to direct people first?
(Continue reading)

Permalink | Reply |

Gmane