Simply due to new work on my libHaru interface app I needed the newest version of libHaru. You may download version 2.1.0 for Windows from the libHaru site.
Building libHaru under Windows is time consuming – strange stuff and lots of people are asking for prebuild libraries under Windows.
I made a build for their 2.3.0 RC2 candidate (software date: 23.01.2012) and it can be downloaded from here.
In der 13.ten Folge unseres Podcast informiert uns Esther Mietzsch vom Squeak e.V. über Squeak in der Ausbildung und Zielsetzung des Vereines.
Viel Spaß dabei
Ok, I tried the stuff today under Ubuntu 10.10 (with standard libzmq 2.0.6 beta) and it crashed.
Then I had to downloaded source code for 2.1.1 (stable version) and compiled and installed the stuff and it worked out of the box (because libzmq.so links to libzmq.so.1).
Ok, next step reached.
With each day doing some work with this framework the wrappers changes. Actually the code from yesterday is snow from yesterday and everything is melting away 
I rearranged and change the class hierarchy and now each Smalltalk item in the 0MQ network is named a “ZMQNode”. The difference between this class and a specific subclass of ZMQSocket (like MSKZMQReplySocket) is, that a node can work with lots of sockets and implements an internal logic in a serialized programming way.
Due to the fact, that the internal logic is implemented as blocks it would be possible to send the node a string with a block definition and let the node call the Smalltalk compiler itself and change its own logic with the new block compiled block definition.
The setup of the needed sockets are now done in a more configurable way:
Considering the request/replay example from the 0MQ guide the setup of both nodes (one is the server, one is the client – each with only one socket):
context := ZMQCore newContext.
"the server"
(node1 := context newNode)
setupFromConfiguration:
(ZMQNodeCfg new initialize
name: 'server' ;
socketCfgs: (OrderedCollection new
add: (ZMQSocketCfg
fromArray: #('push' 'tcp://127.0.0.1:12360' 'push' true ));
yourself);
yourself);
handleBlock: self node1HandleBlock.
"the client"
(node2 := context newNode)
setupFromConfiguration:
(ZMQNodeCfg new initialize
name: 'client' ;
socketCfgs: (OrderedCollection new
add: (
ZMQSocketCfg fromArray: #('pull' 'tcp://127.0.0.1:12360' 'pull' false ));
yourself);
yourself);
handleBlock: self node2HandleBlock.
where the client code (as an example) is now defined in Smalltalk like:
node2HandleBlock
^[ :node |
| socket |
socket := node socketNamed: 'pull'.
[ node continueBlockFlag ] whileTrue:[
| recString |
[
recString := socket receiveStringBlocking.
recString = 'end' ifTrue:[ node abortLoop ].
]
when: ZMQExceptions::ExZMQ do: [ :sig | sig exitWith: nil]
when: ZMQExceptions::ExETerm do: [ :sig | node abortLoop. sig exitWith: nil].
].
].
Remember, that both nodes are running in different Smalltalk processes, having their own external thread running for socket access. Running both nodes (without Transcript work) on a computer in the same image and Smalltalk (for the first) time uses all cores on my machine.
Understanding 0MQ and their “objects” and it’s pretty easy to rewrite the 0MQ based code in a different language – here as an example C#. The interaction between both languages worked at once. There are now more than 30 bindings available for different programming languages (e.g. GnuSmalltalk, Ruby, Java, C++, Erlang, C#, Haskell, …)
string upstreamAddress = "tcp://127.0.0.1:12360";
ZMQ.Socket upstreamSocket = new Socket(SocketType.PULL);
upstreamSocket.Connect(upstreamAddress);
string receivedString = "";
bool continueFlag = true;
while (continueFlag)
{
receivedString = System.Text.Encoding.Default.GetString(upstreamSocket.Recv());
if (receivedString == "end")
{
continueFlag = false;
}
else
{
//System.Console.WriteLine(counter.ToString() + ": " + receivedString);
}
}
upstreamSocket.Dispose();
By the way. The guide of zeromq is a wonderful documentation of different types of distributed computing and connecting all stuff together with zeromq.
Another remark: the “0MQ” sockets are NOT plain sockets. You can not connect a plain socket against zeromq (e.g. with telnet). Therefore its not a replacement for the standard socket interface. If you want to have Smalltalk sockets talks with 0MQ library socket, you must implement “ZeroMQ Message Transport Protocol” in Smalltalk sockets.
Here is another example from the user guide of 0MQ: a classical server-client communication:
Ask and Ye Shall Receive example in the 0MQ Guide
Execute in the workspace:
context := ZMQCore newContext: 1.
special class with additional logic. somehow the
way TobSocket does it ...
Here we define the send socket - using its own
external API thread
socket1 := MSKZMQReplySocket
newIn: context
address: 'tcp://*:5555'
ownCore: true
domain: nil
block: [ :s |
| stringFromClient |
Transcript cr ; show: 'Server Socket Working !'.
[ s continueReceiveLoop ] whileTrue:[
(stringFromClient := s receiveStringNonBlocking) notNil
ifTrue:[
Transcript cr ; show: 'ReplySocket: Message from Client: ', stringFromClient.
s send: 'World'.
]
ifFalse:[ (Delay forMilliseconds: 50) wait ].
].
Transcript cr ; show: 'Server Socket closing !'.
s close.
].
here the server is started:
socket1
startWithBackgroundPriority.
special class for upstream service. Here we give the
socket its own API external thread (core)
socket2 := MSKZMQRequestSocket
newIn: context
address: 'tcp://localhost:5555'
ownCore: true
domain: nil
block: [ :s |
Transcript cr ; show: 'Client Socket Working !'.
1 to: 10 do: [ :anIndex | | continueFlag |
Transcript cr ; show: 'Client sending request !'.
s send: 'Hello'.
continueFlag := true.
[ continueFlag ] whileTrue:[
| receivedString |
(receivedString := s receiveStringNonBlocking) notNil
ifTrue:[
Transcript cr; show: (anIndex printString),': Answer from Server: ',receivedString.
continueFlag := false ]
ifFalse:[ (Delay forMilliseconds: 100) wait ]
]
].
s close.
Transcript cr ; show: 'Client Socket Finished !'.
].
and the socket is started
socket2
startWithBackgroundPriority.
socket2 is closed automatically after all 10 requests are send
and socket1 has to be closed manually by:
socket1 setDomainObjectToFalse
or:
context term
Ok, in the last posting you saw a very simple example and the plain code using the low-level Smalltalk wrapper around the API.
Here – after changing the structure – a more OO like approach in a sense of programming as TobSocket is doing it:
Reference to: http://www.youtube.com/watch?v=_JCBphyciAs&feature=autoplay&list=PLAB622092B91FA1FA&lf=results_video&playnext=4
Execute in the workspace:
context := ZMQCore newContext: 1.
special class with additional logic. somehow the
way TobSocket does it ...
Here we define the send socket - using the external
API thread of context
socket1 := MSKZMQDownstreamSocket
newIn: context
address: 'tcp://127.0.0.1:12345'
ownCore: false
domain: nil
block: [ :s |
(Delay forSeconds: 5) wait.
1 to: 10 do: [ :anIndex |
s send: 'Hello ',(anIndex printString).
(Delay forSeconds: 5) wait.
].
s close.
].
here the server is started:
socket1
startWithBackgroundPriority.
special class for upstream service. Here we give the
socket its own API external thread (core)
socket2 := MSKZMQUpstreamSocket
newIn: context
address: 'tcp://127.0.0.1:12345'
ownCore: true
domain: nil
block: [ :s |
[ s continueReceiveLoop ] whileTrue:[
| receivedString |
(receivedString := s receiveStringNonBlocking) notNil
ifTrue:[ Transcript cr; show: '1: ',receivedString ]
ifFalse:[(Delay forMilliseconds: 100) wait ]
].
s close.
].
and the socket is started
socket2
startWithBackgroundPriority.
socket1 is closed automatically after all 10 messages are send
and socket2 has to be closed manually by:
socket2 setDomainObjectToFalse
or:
context term
I’m in the process of republishing my C-API screencasts episodes at our podcast server – just to have it available at one source.
The work on the IC headless infrastructure is going on only very slowly. Today I had to rearrange the IC structure again and it took a complete one day to get a working IC structure again – only under Windows. The work on Linux will be done, when I need it.
I had to split the large network IC into several parts:
* SstKernel – which is also pretty suitable for Smalltalk non network applications
* NetBase – the base socket communication ic for SSL communication and simple socket communication
* NetSST – more or less the whole ServerSmalltalk Framework.
* TobSocket – well, its a commercial product and therefore it should be isolated from the other stuff
I tried to create ICs for RMI calls and WebServcies, but that did not work. I posted a corresponding message on the forum at Instantiations.
I rewrote the MessagePack library available at vastgoodies to make it more VA-like and I am in the progress of adding MessagePackRPC to the list of available ICs. On top of that a simple Seaside GUI will be put to make adimistration possible.
The general idea is to have MessagePack-RPC as a base to communicate with other programming languages – the first candidate might be here C#.
Other modules will then be able to register method-names at the RPC server and then these services can be called from other languages/systems.
One of these services will be a download/upload service to make it possible to send my VASmalltalk application files from other systems (e.g. pictures).
Then additional modules like the eMan package and a gzip wrapper have to be added and then – based on this work – the work on a new demo project can be started.
We have published our first english (!) podcast – with a very VASmalltalk specific topic – hope you like it: Continous Integration with VASmalltalk.
Thanks to Thomas Koschate for speaking with us about this topic.
