Navigation: Programming Cookbook > Sockets Connectivity >
Talking Objects across a Socket Connection
If you are safe in the knowledge that both ends of a connection are being handled by a Dolphin application then you can make use of an STB Filer to send higher levels of data over the link. As you are probably aware, the STB (Smalltalk Binary) mechanism is able to stream entire object graphs into a serial format and then to rebuild an equivalent set of objects at some destination location.
To send an object across a Socket write stream using the STB mechanism you must first create an STBOutFiler on to the stream. A number of simple or complex objects can then be put to the filer, which will serialize them onto the stream and across the socket connection. To retrieve these objects at a destination Socket you must have an STBInFiler that has been created on the Socket's read stream. It is then simply a matter of pulling the objects from the filer, one by one, using its #next method.
Let us send some more complex objects from socketB to socketA and vice versa. We'll send a Dictionary from the Client to the Server and add some items to it at the Server end. Then we'll return the updated Dictionary back to the Client.
In the Client workspace:
outFilerB := STBOutFiler on: socketB writeStream.
outFilerB nextPut: ##(Dictionary new
at: 'Jones' put: '171 209 9000';
at: 'Smith' put: '181 200 2345';
outFilerB stream flush.
In the Server workspace we receive the Dictionary, add to it, and return it:
inFilerA := STBInFiler on: socketA readStream.
myDictionary := inFilerA next.
myDictionary at: 'Thomas' put: '1785 66928'.
outFilerA := STBOutFiler on: socketA writeStream.
outFilerA nextPut: myDictionary.
outFilerA stream flush.
Now, back in the Client workspace, we'll receive the returned Dictionary and display it to confirm that it has the new entry.
inFilerB := STBInFiler on: socketB readStream.
inFilerB next. "Display it"
Tip: when you create an STBInFiler onto a Socket read stream, this operation will generally block. This is because the filer initially attempts to read some header information from the stream. If this is inconvenient then you should ensure that the STBOutFiler at the other end of the connection is always created first, and the stream flushed, so that the header information is immediately available at the receiving end.