socket programming intro

> Günther,
>
>> I'd need an intro to socket programming, I'm absolutely clueless on
>> even the basics.
>
>
> You aren't going to like this :)  The truth about sockets programming is
> that it will seem easy when and not before you are "ready".
>
>
>> One for Smalltalk would be great.
>>
>> HELP!
>
>
> Google might turn up something, as might a search of Ian's archives of
> this group.  Generally, you will get read and write streams over a
> socket, and go at it; Dolphin's socket streams will save you an enormous
> amount of work; don't fight them.
>
> Protocols tend to be either text or binary.  Text protocols will use
> cr/lf or some other type of delimiter of "lines".  Binary protocols tend
> to send a fixed-size number of bytes followed by the data; sometimes,
> they close a socket to indicate the end of the data.
>
> Dolphin has a chat sample that will teach you a lot.  If you have an
> SMTP server that will talk to you, sending mail is an excellent project.
>  At least up to the point that you start sending attachments, it's
> really quite easy to do.  An HTTP client is more ambitious.  Squeak has
> some good examples to follow.
>
> I tend to use separate threads for reading and writing, and synchronize
> (see Mutex, #critical:, Semaphore, #wait, #signal, shared collections)
> them as appropriate to the protocol.  Sometimes the sending part is best
> handled using a shared queue to accept things to be sent, with the send
> thread reading from it, doing any marshaling ("formatting") and sending
> the data over the write stream.  Reading usually involves a loop that
> looks for "messages" and then parses and acts on them.
>
> Servers and clients are sometimes blurred.  One server-like job is
> listening for and accepting connections.  Clients can do that too.  A
> client-like job is to have or prompt for an IP name or number (perhaps
> resolving a name to get a number) and then connecting.  When you are
> starting, it helps to write a text-only server and to use a Telnet
> client to talk to it.  You will learn a lot just by accepting
> connections and getting text on the telnet window.
>
> Error handling is a critical part of any good network software, and will
> probably take the most effort to get right.  #ensure: blocks can be very
> helpful.  I tend to have each thread do its own cleanup, so that no
> matter how it exists (normal end of conversation, #terminate, untrapped
> error, etc.), everything gets closed to the extent possible.  Note that
> read and write threads will typically want to try to close each other,
> and must recognize that other might not exist; they also need to
> synchronize their efforts via critical sections or some other mechanism.
>
> There are ways to avoid threads, but I don't recommend them; threads
> will give you a cleaner representation than the procedural alternatives.
>   You will need to learn to sort out deadlocks, but that's actually not
> too difficult to do.  See my ProcessViewer goodie, as well as Dolphin's
> Process Monitor.  Both have a roll.  My goodie is particularly well
> suited to deadlocks that arise from a critical section that
> inappropriately spans a wait.  If that does not make sense, don't worry
> - it will.
>
> Note that servers and clients can stop responding, and networks can be
> unreliable.  Stream sockets should never errantly tell you they
> succeeded in transmitting data, but they can fail to tell you they
> failed to do so.  See my TimedEvaluators package for some ways to
> protect you and your users from waiting forever.
>
> All of this is somewhat analogous to learning Smalltalk.  It's very
> complicated at first, but then forms a very clear picture with a few
> important concepts that end up being quite powerful.  Learn about them,
> and they will serve you well.
>
> Have a good one,
>
> Bill
>