I think it's about time you took a deep breath....
>How I wish I could get some documentation on the new socket related commands
>in B2!
>
>Diving into to undocumented stacks and trying to figure out what parameters
>are passed, and whether all the features are supported on all platforms can
>be fun (when all goes well). Today I'm miserable, cos I'm going round in
>circles -:)
>
>read from socket <s> [for | until <cond>] [with message <m>]
>
>OK, well it would be nice to find out what the definition and syntax of a
>socket <s> was. Answer simple, click on the word socket for the definition,
>and <s> for the syntax. But, after a number of days and lot's of very
>helpful postings, I still don't know, and what's worse when I do no one else
>will, (save the few people who would read the post).
This is what I posted a few days ago
One definition would be:
"A socket is an endpoint for communication. Two cooperating sockets,
one on the local machine and one on the remote machine, form a
connection. Each of the two sockets has a unique address..."
>
>Am I moaning?
You try to learn too much in one day...
>Not the sort really, so I'm offering my services (not quite a
>promiss), to improve on the "Metatalk Reference" stack.
>
>Back to the socket stuff...
>
>1) What is the differnece between a socket and a port? (opensockets()
>returns 80 - which is the port I set but I can get lots of sockets opened on
>this port, so...? Is this something to do with one of the mysterious
>parameters passed to mc after you've issued and "accept..."
Not easy to explain...You need to specify which port is open for business;
if a client writes something to your address at that port you deal with it.
The mysterious parameters you refer to are just instructions to MC what to
do if some data comes at port X.
>
>mc ref states:
>
>The accept command accepts TCP connections or UDP datagrams from other
>systems or processes and creates a new socket that can be used to read or
>write to that other process or system. When one arrives, the specified
>message is sent with a first parameter that is the IP address of the other
>end of the socket. If it is a datagram, a second parameter containing the
>actual data is also included.
>
>Well it's not a simple IP address as I know it it's got a "|" and big
>number after it. Perhaps this is the elusive socket stuff? Not sure yet...
>
>Now let's look at "stdin"
>
>-------------------
>mc ref states:
>
>The read command reads from a file or process specified by the expression
><name>, putting the characters read into the local variable "it". Note that
><name> is case sensitive on all platforms, so you must pass exactly the same
>string passed to the open command.
>
>The constant stdin can also be used to read from MetaCard's standard input
>on UNIX systems (stdin is opened by default, no need to open it with the
>open command).
>
>The result will be set to the string eof when an end-of-file was encountered
>during the read, or to an error message if some other error occured. An
>empty result indicates a successful read.
>---------------------
>
>Well, well... I wonder if "stdin" is case sensitive? And what is the syntax
>to read from it? After lot's of experimentation, I got it so mc does not
>complain, but does it work on the Mac? If not, I think I have a problem, as
>I want to get the form data from a "POST" and that is supposed to go to
>"stdin"? I think.
To get the data from a POST you need to read the whole header since the
actual POST parameters are at the end of it. I prefer to use forms with GET
where the data is on the first line. IF I have time I'll try to post a
sample script for POST.
>
>And read from socket...
>
>-------------------
>mc ref states:
>
>The "read from socket" command is used to read data from a socket. Sockets
>are always opened in binary mode and so any required data conversion must be
>done in scripts. If the optional "message" parameter is supplied, a message
>will be sent when the read completes, otherwise the read blocks until the
>data has been read. If no "for" or "until" condition is supplied, the
>message will be sent when any data arrives at the socket.
>-------------------
>
>
>Well as usual any help is appreciated, and I promise to write this up when I
>figure it out. Still don't get this UNIX world. Lack of clarity and
>documentation seem to be the norm. It's kind of "if you don't know, don't
>ask" - present company excluded -:)
Regards, Andu
