Network training

Hi,

I am playing with Network package.
I am giving a practical work to my students, in Java :(
And I am doing the same in Pharo to understand the Network package :)))

A first question:
I use "NetNameResolver localHostAddress" to retrieve my network address. Now in computers, there are multiple addresses.
I do not find a method to retrieve a collection of my address and it seems to be not possible, because it uses primLocalAddress, which is a primitive returning one local address.

Does it exist something to have all my ip address?

Thank you,



---
Jannik Laval

On 4 févr. 2011, at 06:43, jannik.laval wrote:

>
> A first question:
> I use "NetNameResolver localHostAddress" to retrieve my network address. Now in computers, there are multiple addresses.
> I do not find a method to retrieve a collection of my address and it seems to be not possible, because it uses primLocalAddress, which is a primitive returning one local address.
>
> Does it exist something to have all my ip address?
>
I'm not aware of such thing, though we need it.
Note that you can however force a server socket to listen for connections on any IP of your machine.

Noury

Thanks jannik

this is an important action.

Stef

On Feb 4, 2011, at 6:43 AM, jannik.laval wrote:

but how can i find these ip address in pharo?



Le 4 févr. 2011 à 07:49, Noury Bouraqadi <[hidden email]> a écrit :

On 4 February 2011 09:19, Laval Jannik <[hidden email]> wrote:
> but how can i find these ip address in pharo?
>
>
perhaps by writing new primitive :)




--
Best regards,
Igor Stasenko AKA sig.

I've started to play a little bit with network, you can see the repo: SockectExamples (you should have been added as dev) ;)


Ben

On Feb 4, 2011, at 9:48 AM, Igor Stasenko wrote:

Now, another thing, the method: NetNameResolver>>isConnected.

On Fri, 4 Feb 2011, jannik.laval wrote:

Yes. The network changes that were introduced in Pharo 1.1 and were
reverted before the release contained such methods. In theory both the VM
side and client side code is ready for this (Etoys uses it on OLPC), but
some VMs (e.g. Cog) don't have the latest plugin versions, so the
primitives don't work there.


Levente

On 4 févr. 2011, at 12:38, jannik.laval wrote:
I don't think so.
An alternative might be to use an Ocean-like approach and call OS features directly through some FFI.
No.

Luc and I decided that it does not worth it struggling with the plugin.
This is why we initiated the Ocean project (plugin-free networking) available on SqueakSource.

We made interesting (though slow) progress so far.
Currently we have a complete library for TCP client socket.
For the server socket to be usable we need multithreading Alien which is not available yet. Hope Eliot will have time to work on this soon or may be we'll get NativeBoost working on all major platforms (Go Igore!!!).

Instead of remaining stalled or hacking some temporary solution, we changed a bit our strategy in order to have (hopefully) support for TCP sockets ready for Pharo 1.3. Our idea is that the limitations of networking problem have 2 origins: The poor library and the plugin.

We decided to put all our effort on the library and having it work with the plugin. We are re-writing it fully with tests.
Our design is independent of the low-level network support (Bridge pattern).
So, we can (didn't test yet) be able to work either with the plugin or with any external networking library, through Alien or other FFI.
Once we'll be done with the library, we'll tackle the plugin issue.

The Ocean is wide, we have to row a lot ;-)
Noury

I think that your new strategy is really good!

Stef

>>>> We decided to put all our effort on the library and having it work with the plugin. We are re-writing it fully with tests.
> Our design is independent of the low-level network support (Bridge pattern).
> So, we can (didn't test yet) be able to work either with the plugin or with any external networking library, through Alien or other FFI.
> Once we'll be done with the library, we'll tackle the plugin issue.
>
> The Ocean is wide, we have to row a lot ;-)
> Noury
>

On Fri, 4 Feb 2011, Noury Bouraqadi wrote:
There is. See my previous mail in this thread.
Plugin-free networking doesn't exist. You either use the SocketPlugin,
FFIPlugin or the plugin for Alien.


Levente

On Fri, 4 Feb 2011, Luc Fabresse wrote:

> Yes, but hopefully we will be SocketPlugin free.

Is SocketPlugin buggy?
If yes, where's the bug report?
If not, what's the problem with it?

> At the end, "There can be only one" (FFI or Alien or NB or a better one) ;-)
> IMHO, plugins are a pain to understand, maintain, integrate in the latest
> VM...
> so let's kill them as much as possible.

Maintaining SocketPlugin (or reimplementing for a new plaform) is a lot
easier than doing the same with FFI or Alien. Eliot's threaded FFI plugin
is very complex compared to (the pretty simple) SocketPlugin.


Levente

On 5 February 2011 00:12, Levente Uzonyi <[hidden email]> wrote:
> On Fri, 4 Feb 2011, Luc Fabresse wrote:
>
>> Yes, but hopefully we will be SocketPlugin free.
>
> Is SocketPlugin buggy?
> If yes, where's the bug report?
> If not, what's the problem with it?
>
Just one: it is highly resistant to evolution and changes. As well as
everything else in VM.

>> At the end, "There can be only one" (FFI or Alien or NB or a better one)
>> ;-)
>> IMHO, plugins are a pain to understand, maintain, integrate in the latest
>> VM...
>> so let's kill them as much as possible.
>
> Maintaining SocketPlugin (or reimplementing for a new plaform) is a lot
> easier than doing the same with FFI or Alien.

I wouldn't say so.

> Eliot's threaded FFI plugin is
> very complex compared to (the pretty simple) SocketPlugin.
>
>
It could be simple too. But just not fast enough :)
There's always a lot of tradeoffs to consider.

> Levente
>
>



--
Best regards,
Igor Stasenko AKA sig.

On Sat, 5 Feb 2011, Igor Stasenko wrote:

Does the Socket API change often? No. I'm sure all my 10 years old network
code (written in C) would compile and run on the first try.

Why?

Couldn't you reimplement SocketPlugin from scratch without looking at the
current implementation in at most a few days? I could, so I'm sure you
could do that too. The same is not true for FFI or Alien (at least not
for me).

>
>> Eliot's threaded FFI plugin is
>> very complex compared to (the pretty simple) SocketPlugin.
>>
>>
> It could be simple too. But just not fast enough :)
> There's always a lot of tradeoffs to consider.

It could be, but it's not.


Levente

On 5 February 2011 00:53, Levente Uzonyi <[hidden email]> wrote:
I can tell you more:
Does C syntax changes often? No. So, then why there so many silly
people wasting their time writing own compilers for it?
Or why people inventing new languages? Isn't C enough? :)

Levente, when is the last time you checked the meaning of word
'development' in dictionary?

Because coding in smalltalk much easier than in C.
Including cases, when you need to communicate with external library using C ABI.

Otherwise, why would i be sitting here? And why VM written in
smalltalk?.. For same reason, bro :)

> Couldn't you reimplement SocketPlugin from scratch without looking at the
> current implementation in at most a few days? I could, so I'm sure you could
> do that too. The same is not true for FFI or Alien (at least not for me).
>

So you have something to learn left in this world :)

You will never know if you don't try.

And besides, what is your point?
People learning network by implementing own network layer. Exploring
something new and trying to adopt design
to their own vision/mindset.
Now you came and saying "you are on the losing side, because A, B, C"..
Do, you think people should learn SocketPlugin instead? Been there did
that. Frankly, don't want to touch it again or teach people about it.
I seen much more cleaner and robust socket library OO wrappers. Not in
smalltalk though.

P.S. Don't take me wrong. Yes there is a lot to learn from
SocketPlugin. But you would better spend time learning/reading other
well written and well documented multithreaded library for serving
socket connections.


>
> Levente
>


--
Best regards,
Igor Stasenko AKA sig.

On Sat, 5 Feb 2011, Igor Stasenko wrote:

Why do you compare APIs wrapping the OS's socket API to programming
languages? I don't see how is the two similar at all.

>
> Levente, when is the last time you checked the meaning of word
> 'development' in dictionary?

I can tell you what's not developement: Throwing away working solutions
without a reason, then writing something similar. That's reinventing the
wheel + optional NIH syndrome.

That's not an anwser to my question, but I see your point.

>
>> Couldn't you reimplement SocketPlugin from scratch without looking at the
>> current implementation in at most a few days? I could, so I'm sure you could
>> do that too. The same is not true for FFI or Alien (at least not for me).
>>
>
> So you have something to learn left in this world :)

Lol...

I'm talking about Eliot's FFI implementation, while you're talking about
something else.

>
> And besides, what is your point?
> People learning network by implementing own network layer. Exploring
> something new and trying to adopt design
> to their own vision/mindset.

There's nothing wrong with that, until they don't start saying that the
plugin sucks without telling what's the problem with it.

> Now you came and saying "you are on the losing side, because A, B, C"..
> Do, you think people should learn SocketPlugin instead? Been there did
> that. Frankly, don't want to touch it again or teach people about it.
> I seen much more cleaner and robust socket library OO wrappers. Not in
> smalltalk though.

And you're doing the same now. You say it sucks, but you don't tell what's
wrong with it.

>
> P.S. Don't take me wrong. Yes there is a lot to learn from
> SocketPlugin. But you would better spend time learning/reading other

I didn't say that anyone should learn from SocketPlugin. Forget the
plugin. People should learn how the API works that SocketPlugin provides.
Not many people know how to use it according to my earlier discussions on
this list about networking.

> well written and well documented multithreaded library for serving
> socket connections.

Without pointing to those better libraries and the things they do better
than the current solution, this is just an empty phrase.


Levente

Hi Levente,

Thank you for the answer, but it is not clear for me where is this source code.
You are saying that the VM includes already something like that, does the 5.7 (non-cog) includes it ?
And how can I find the source code ? I will try to search on eToys image.

Why was in included in removed from Pharo ?

Jannik

On Feb 4, 2011, at 13:24 , Levente Uzonyi wrote:

On Feb 5, 2011, at 8:42 AM, jannik.laval wrote:

> Hi Levente,
>
> Thank you for the answer, but it is not clear for me where is this source code.
> You are saying that the VM includes already something like that, does the 5.7 (non-cog) includes it ?
> And how can I find the source code ? I will try to search on eToys image.
>
> Why was in included in removed from Pharo ?
>
Because it did not work and we did not have the resources to debug it.

        Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.

Maybe I can do a try.
Do you have sources ?

Jannik

On Feb 5, 2011, at 08:47 , Marcus Denker wrote: