Re: sockets: a revelation

[Kevin Miller]

On 4/11/00 10:27 am, Xavier Bury <[EMAIL PROTECTED]> wrote:

> ok, but how do you read the info or request it?
> suppose you know the ip and port to use only?
> 
> does anyone have an explanation about how to read datagrams?
> how do you discover the protocol? is this necessary?
> 
> for example, i'd like to list quake servers available...
> how do you go about finding this out?
> 
> i've searched for possible info on the web but it's too polluted with
> scripts, tricks and tweaks...
> 
> a url will do surely!

These games all use their own protocols, you would have to have inside
information or some documentation to have any chance of figuring out how to
talk to them.  However, if you just want to try out sockets, a most basic
example (posted previously) would be:

> The following scripts work well for me in local one-machine tests. They
> require two stacks: a metacard "server" stack and the client stack. You will,
> of course, need to replace the "1.1.1.1" with your actual IP/domain name...
> 
> In the server, I put:
> 
> on openCard
> accept connections on port 8080 with message gotOne
> end openCard
> 
> on gotOne theSocket
> write "OK" to socket theSocket
> close socket theSocket
> end gotOne
> 
> In the client:
> 
> on openCard
> checkOnline
> end openCard
> 
> on checkOnline
> open socket to "1.1.1.1:8080" with message gotcha
> send "checkOnline" to this card in 10 seconds
> end checkOnline
> 
> on gotcha s
> read from socket s for 1 line
> if (it = "OK") then put "Looks like we are online at"&&(the long time)
> else answer "Looks like the server is not responding."
> close socket s
> end gotcha
> 
> on socketError
> answer "Looks like we are offline."
> end socketError

Regards,

Kevin

> im not refering to cgi's btw.
> 
> Thanks
> Xavier

Kevin Miller <[EMAIL PROTECTED]> 
Runtime Revolution Limited (formerly Cross Worlds Computing).
Tel: +44 (0)131 672 2909.  Fax: +44 (0)1639 830 707.


Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.

RE: sockets: a revelation

[Xavier Bury]

i'll answer my own questions...

> ok, but how do you read the info or request it?
> suppose you know the ip and port to use only?

according to what i saw in the ftp client made with MC (listed in the
www.xworlds.com contributions...
What you have to do is to open the socket
The port is for example 80 for a web server, 21 for ftp, etc (see the RFCs
(ez to find at yahoo) for most common server formats). Other programs like
game servers or particular programs (CUCME, Roger Wilco, Hotline,
MSNMessenger, etc...) depend on the program. Finding those protocols and
datagrams is not easy. You'll have to look for source code or sniff the
packets... Source code is usually easier to find.

(Debugging note: a firewall program can block your packets so make sure that
they pass first. You can ping the server for example but some firewalls will
block either the address (websense.com) or the ports or any combination of.
Ask the net administrator at your work place. Just remember that this would
imply that the program you would try to emulate would not work either since
they would also be blocked.)

Once you've opened the socket using the right "ip:port" url, you'll have to
send it some datagrams or a message.
For http, it's a message and for a quake server it's a datagram.
If you dont send anything, the connection will simple open and close
(right?).

So you write the socket a query
  in http, it can be "GET,OPTIONS,etc... (thanks to Spade.org)

in quake, you have to send it datagrams (thanks to Qstats and source code at
http://www.activesw.com/people/steve and Luc the fragmaster at
http//3d.win.be/

if you dont do that, you wont get anything...
i still havent got anything from any quake servers yet but soon i hope!

The FTP client is a great example on how to use the sockets
and you can read it's source in the stack script.
It's a good explanation of how an ftp server works!

im writting a socketsbrowser, it should be ready for xmas!



Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.

Re: sockets: a revelation

[Kevin Miller]

On 4/11/00 4:02 pm, Monte Goulding <[EMAIL PROTECTED]> wrote:

> This may be a bit off your topic but it's still about sockets. I have never
> played with this so am just asking through curiosity. My field of study and
> work is in Exercise and Sports Science. In this field (and may others I
> might add) there are a lot of gadgets as you would understand that fit to
> port. Is it possible to read directly from these gadgets or is this only
> possible if you know the messages they are sending. Is this legal if it
> side-steps software designed buy the manufacturer of the gadget. I would be
> quite interested to find out this kind of info for future reference. I am
> really not up to it yet.

Again, this may be possible reading and writing to serial ports - it
wouldn't be sockets in this case (unless these devices talk Internet
protocols!).

Regards,

Kevin

Kevin Miller <[EMAIL PROTECTED]> 
Runtime Revolution Limited (formerly Cross Worlds Computing).
Tel: +44 (0)131 672 2909.  Fax: +44 (0)1639 830 707.


Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.

RE: sockets: a revelation

[Xavier Bury]

ok, but how do you read the info or request it?
suppose you know the ip and port to use only?

does anyone have an explanation about how to read datagrams?
how do you discover the protocol? is this necessary?

for example, i'd like to list quake servers available...
how do you go about finding this out?

i've searched for possible info on the web but it's too polluted with
scripts, tricks and tweaks...

a url will do surely!
im not refering to cgi's btw.

Thanks
Xavier

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Monte Goulding
> Sent: Saturday, November 04, 2000 5:02 PM
> To: [EMAIL PROTECTED]
> Subject: Re: sockets: a revelation
>
>
>
> Hi
>
> This may be a bit off your topic but it's still about sockets. I
> have never
> played with this so am just asking through curiosity. My field of
> study and
> work is in Exercise and Sports Science. In this field (and may others I
> might add) there are a lot of gadgets as you would understand that fit to
> port. Is it possible to read directly from these gadgets or is this only
> possible if you know the messages they are sending. Is this legal if it
> side-steps software designed buy the manufacturer of the gadget.
> I would be
> quite interested to find out this kind of info for future reference. I am
> really not up to it yet.
>
> Regards
>
> Monte
>
> >From: Dave Cragg <[EMAIL PROTECTED]>
> >Reply-To: [EMAIL PROTECTED]
> >To: [EMAIL PROTECTED]
> >Subject: sockets: a revelation
> >Date: Fri, 3 Nov 2000 14:16:48 +
> >
> >Hi all,
> >
> >Sorry for this rambling mail, but I just had one of those "see the
> >light" experiences that leaves you feeling both like a genius and an
> >idiot at the same time.
> >
> >Like others I guess, I've been trying to get to grips with the new
> >sockets features of Metacard, and seeing how these can be used for
> >various internet/intranet purposes. So I've been doing some reading
> >up of various internet protocols and tried to implement some
> >client-side http as part of this.
> >
> >Anyway, all this attention to web protocols seems to have blinded me
> >to the basic concept of sockets. I've been approaching the whole
> >thing with the premise that it's necesary to use established
> >protocols (ftp, http, etc.) to use sockets. However, it just came to
> >me that client and server programs can communicate any way they like,
> >as long as they can understand each other.
> >
> >I have to thank Brian (Yennie) of this list for this "discovery".
> >While browsing some old mails, I came across his scripts for checking
> >whether a computer was still online or not. I couldn't believe it was
> >that simple. ("accept connections on port 8080 with message whatever"
> >and your server application is running. Come on, Scott! This is
> >embarrassingly easy. Who's going to take this seriously? :))
> >
> >I can see the importance of implementing established protocols if you
> >need to communicate widely, for example, to apache servers from
> >client Metacard programs or with web browsers from a Metacard server
> >program. However, my interest is with more restricted applications.
> >In particualr, with intranet-based training programs where a single
> >Metacard client program has to communicate with an intranet server
> >program to process results , be served lessons, tests, etc.
> >
> >Instead of grappling with cgi scripting, web protocols and the like,
> >it seems all I have to do is put a Metacard program on an accessible
> >machine, set it to accept connections, and then basically implement a
> >set of matching read/write handlers at the client and server ends. A
> >private protocol, so to speak.
> >
> >So my questions:
> >
> >Is it really this easy, in principle at least?
> >
> >What are the pitfalls?
> >
> >Is Metacard ready for the big time in this regard? (I.e. will it run
> >all day on a server?)
> >
> >Aplogies if all this is blindingly obvious.
> >
> >Cheers
> >Dave Cragg
> >
> >Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
> >Info: http://www.xworlds.com/metacard/mailinglist.htm
> >Please send bug reports to <[EMAIL PROTECTED]>, not this list.
> >
>
> _
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
> Share information about yourself, create your own public profile at
> http://profiles.msn.com.
>
>
> Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
> Info: http://www.xworlds.com/metacard/mailinglist.htm
> Please send bug reports to <[EMAIL PROTECTED]>, not this list.
>


Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.

Re: sockets: a revelation

[Monte Goulding]

Hi

This may be a bit off your topic but it's still about sockets. I have never 
played with this so am just asking through curiosity. My field of study and 
work is in Exercise and Sports Science. In this field (and may others I 
might add) there are a lot of gadgets as you would understand that fit to 
port. Is it possible to read directly from these gadgets or is this only 
possible if you know the messages they are sending. Is this legal if it 
side-steps software designed buy the manufacturer of the gadget. I would be 
quite interested to find out this kind of info for future reference. I am 
really not up to it yet.

Regards

Monte

>From: Dave Cragg <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: sockets: a revelation
>Date: Fri, 3 Nov 2000 14:16:48 +
>
>Hi all,
>
>Sorry for this rambling mail, but I just had one of those "see the
>light" experiences that leaves you feeling both like a genius and an
>idiot at the same time.
>
>Like others I guess, I've been trying to get to grips with the new
>sockets features of Metacard, and seeing how these can be used for
>various internet/intranet purposes. So I've been doing some reading
>up of various internet protocols and tried to implement some
>client-side http as part of this.
>
>Anyway, all this attention to web protocols seems to have blinded me
>to the basic concept of sockets. I've been approaching the whole
>thing with the premise that it's necesary to use established
>protocols (ftp, http, etc.) to use sockets. However, it just came to
>me that client and server programs can communicate any way they like,
>as long as they can understand each other.
>
>I have to thank Brian (Yennie) of this list for this "discovery".
>While browsing some old mails, I came across his scripts for checking
>whether a computer was still online or not. I couldn't believe it was
>that simple. ("accept connections on port 8080 with message whatever"
>and your server application is running. Come on, Scott! This is
>embarrassingly easy. Who's going to take this seriously? :))
>
>I can see the importance of implementing established protocols if you
>need to communicate widely, for example, to apache servers from
>client Metacard programs or with web browsers from a Metacard server
>program. However, my interest is with more restricted applications.
>In particualr, with intranet-based training programs where a single
>Metacard client program has to communicate with an intranet server
>program to process results , be served lessons, tests, etc.
>
>Instead of grappling with cgi scripting, web protocols and the like,
>it seems all I have to do is put a Metacard program on an accessible
>machine, set it to accept connections, and then basically implement a
>set of matching read/write handlers at the client and server ends. A
>private protocol, so to speak.
>
>So my questions:
>
>Is it really this easy, in principle at least?
>
>What are the pitfalls?
>
>Is Metacard ready for the big time in this regard? (I.e. will it run
>all day on a server?)
>
>Aplogies if all this is blindingly obvious.
>
>Cheers
>Dave Cragg
>
>Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
>Info: http://www.xworlds.com/metacard/mailinglist.htm
>Please send bug reports to <[EMAIL PROTECTED]>, not this list.
>

_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.


Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.

Re: sockets: a revelation

[andu]

>
>At 10:27 AM -0500 11/3/00, andu wrote:
>
>>Well, if you consider a server some app that's just listening.
>
>Hi Andu
>
>I was thinking of the ease of installation, not the complexities of 
>the server app itself. Your http stack is a great example of this. 
>I'm still surprised that clicking the "Start Server" button is all 
>you need to have a web server running. Somehow I associate starting a 
>web server with configuring various files, and lots of digging around 
>in the OS.

That tells you how complex mchttpd is;-)

>
>>>
>>>What are the pitfalls?
>>
>>Only your specialized clients will ever be able to communicate with 
>>the server.
>
>True. But I wonder how many situations there are where this is all 
>that is needed.
>
>At the very least, I have new toy. :)
>
>Cheers
>Dave
>
>Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
>Info: http://www.xworlds.com/metacard/mailinglist.htm
>Please send bug reports to <[EMAIL PROTECTED]>, not this list.
>
>.


Regards, Andu 
___
[EMAIL PROTECTED]

Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.

Re: sockets: a revelation

[Dave Cragg]

At 10:27 AM -0500 11/3/00, andu wrote:

>Well, if you consider a server some app that's just listening.

Hi Andu

I was thinking of the ease of installation, not the complexities of 
the server app itself. Your http stack is a great example of this. 
I'm still surprised that clicking the "Start Server" button is all 
you need to have a web server running. Somehow I associate starting a 
web server with configuring various files, and lots of digging around 
in the OS.

>>
>>What are the pitfalls?
>
>Only your specialized clients will ever be able to communicate with 
>the server.

True. But I wonder how many situations there are where this is all 
that is needed.

At the very least, I have new toy. :)

Cheers
Dave

Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.

Re: sockets: a revelation

[andu]

>
>Hi all,
>
>Sorry for this rambling mail, but I just had one of those "see the 
>light" experiences that leaves you feeling both like a genius and an 
>idiot at the same time.
>
>Like others I guess, I've been trying to get to grips with the new 
>sockets features of Metacard, and seeing how these can be used for 
>various internet/intranet purposes. So I've been doing some reading 
>up of various internet protocols and tried to implement some 
>client-side http as part of this.
>
>Anyway, all this attention to web protocols seems to have blinded me 
>to the basic concept of sockets. I've been approaching the whole 
>thing with the premise that it's necesary to use established 
>protocols (ftp, http, etc.) to use sockets. However, it just came to 
>me that client and server programs can communicate any way they like, 
>as long as they can understand each other.
>
>I have to thank Brian (Yennie) of this list for this "discovery". 
>While browsing some old mails, I came across his scripts for checking 
>whether a computer was still online or not. I couldn't believe it was 
>that simple. ("accept connections on port 8080 with message whatever" 
>and your server application is running. Come on, Scott! This is 
>embarrassingly easy. Who's going to take this seriously? :))

Well, if you consider a server some app that's just listening.

>
>I can see the importance of implementing established protocols if you 
>need to communicate widely, for example, to apache servers from 
>client Metacard programs or with web browsers from a Metacard server 
>program. However, my interest is with more restricted applications. 
>In particualr, with intranet-based training programs where a single 
>Metacard client program has to communicate with an intranet server 
>program to process results , be served lessons, tests, etc.
>
>Instead of grappling with cgi scripting, web protocols and the like, 
>it seems all I have to do is put a Metacard program on an accessible 
>machine, set it to accept connections, and then basically implement a 
>set of matching read/write handlers at the client and server ends. A 
>private protocol, so to speak.
>
>So my questions:
>
>Is it really this easy, in principle at least?

Yes.

>
>What are the pitfalls?

Only your specialized clients will ever be able to communicate with the server.

>
>Is Metacard ready for the big time in this regard? (I.e. will it run 
>all day on a server?)
>
>Aplogies if all this is blindingly obvious.
>
>Cheers
>Dave Cragg

Regards, Andu 
___
[EMAIL PROTECTED]

Archives: http://www.mail-archive.com/metacard@lists.runrev.com/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.