Using sockets

[Peter Haworth]

Thanks for the explanations Bjornke.  I have been prowling around the web
for more info and found a topic on Stack Overflow attempting to explain the
difference between a socket and a port - lots of responses with many
different analogies!  It seems to be a common source of confusion but at
least my test server and client stacks seem to be working so I think I have
it straight now.

I do have one strange situation.  When my client closes the socket to the
server, the server still seems to be able to communicate with it, not sure
why that would be (other than my code not doing things correctly).

Pete
lcSQL Software <http://www.lcsql.com>
Home of lcStackBrowser <http://www.lcsql.com/lcstackbrowser.html> and
SQLiteAdmin <http://www.lcsql.com/sqliteadmin.html>


On Thu, Jan 16, 2014 at 3:45 AM, Björnke von Gierke <bvg at mac.com> wrote:

> On 15.01.2014, at 01:14, Peter Haworth <pete at lcsql.com> wrote:
>
> > The dictionary adds to the confusion when, in the write to socket entry,
> it
> > says the socket id is an ip address followed by a port when it's actually
> > followed by a socket.
>
> I agree that there's some small inconsistencies in naming sockets vs.
> ports, but it's actually easy.
>
> For example, if you think of IP's as houses, then ports are their
> (thousands of) doors. Sockets are the little roads between two of those
> doors (yes even for the same house). Unlike in the real world, those roads
> are only constructed and paved when you open a socket. The communication
> happens as so called packets, you can imagine those as very stupid
> pedestrians, whom always will follow a single road (Note that LC does a
> great job at obsfucating the packeted nature of IP communication).
>
> So a socket is always a connection between two ports. One of them is
> always the server, and the other is always the client. As a test, try to
> open a port, and query the openSockets, it will list the open ports. You'll
> see an outgoing port on the server, and an incoming port on the client.
> They exist because there's a socket opened.
>
> > However it only mentions the socketTimeoutInterval.
>
> I found the socketTimeout message to be useless. Here's some of it's
> properties (from memories of a few years back, I could be remembering wrong
> on some of these):
>
> - It will fire if nothing is happening on the socket (no reads or writes
> pending), in regular intervals
> - It will fire if a non-blocking read or write is pending or unhandled
> - It will fire during long reads or writes, while they are happening
> - It will not fire if there is no socket open
>
> In other words, according to LC, everything is always timing out, making
> the message completely useless in my view (maybe it can be used to find out
> that the socket is unexpectedly closed, because there sure as hell is no
> other way to find that important info out in LC...).
>
>
> --
>
> Use an alternative Dictionary viewer:
> http://bjoernke.com/bvgdocu/
>
> Chat with other RunRev developers:
> http://bjoernke.com/chatrev/
>
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>