In this example there are two computers, client and server. The client's IP address is, let's say, 10.0.0.1. It will connect to the server (IP: 10.0.0.2) on TCP port 12345. Here's the code each side runs:

later. This makes a lot of sense, I'm sure, but seems a bit counter-intuitive to us less-immersed types.

While the example above certainly works and is the simplest possible, something more will need to be done if you want to have an ongoing conversation between client and server once the connection is made. At this point the only handle we have on the readable/writable socket (which is NOT returned by the socket -server call) is $chan. $chan, which points to the socket channel, is local to the proc accept (and dies with it), but the channel itself is not. So, we can

Since we're not relying on close $chan to flush the channel, we have to do it explicitly. If we're going to be communicating with newline-terminated strings only, we can use fconfigure to automate the flushing.

(At the risk of straying too far from the intent of this page as declared in its title) if the conversation that will then ensue will not follow a rigid script, blocking issues will arise. This means that if the client has not sent anything, then

gets $::realS

will hang your application until the client does send something. To avoid this, we should use fileevent to manage pulling data off the socket when available.

handleComm will be called every time the client side flushes data to the socket. In the meantime, the name of the socket channel is held in the event registered by fileevent. Of course, fconfigure and fileevent are identically applicable on the client side. We could then perhaps call this the simplest possible useful socket demonstration.