ECS-L Home Automation and Security Archives
  learn more | view messages for this month | NetBloc® | terms of use | search

Google
 


  subject (prev) or (next) | time (prev) or (next) | author (prev) or (next) | view more subjects

Subject:
From:
Date:
Re: [ECS] Socket Connection
Dario Greggio
Sun, 07 Jan 2001 23:02:01 +0100

Ingo Pakleppa wrote:

> Maybe before getting started on such a project, it would be a good idea to
> figure out how the socket connections would be used.

This for sure: it'd be useless to implement everything if later it won't
be used.
I've found or created C++ classes for almost every protocol, from HTTP
to FTP to SMTP and POP and Time servers.
In the beginning I was thinking, for instance, about using emails to
send "orders" to my system. Then it came the internet and/or intranet
and since then HTTP has seemd to be the perfect way to do all of these
things: through HTTP you can display pages with whatever you need, and
you can send commands, you can have webcams and stream MP3.
So, now I only use POP and SMTP to give "best wishes" to my friends
automatically!
FTP maybe a good thing if you need to upload files to your system, but
it happens quite seldom: and if you need to download whichever kind of
file then HTTP is good enough.

> If you are talking about binary data, it would be nice or even necessary to
> have support for the most common binary-to-ascii conversions and mime types [...]

I think that it would be very good to have a "low-level" socket
implementation to get out of trouble in particular circumstances, but
the bigger work should be done with a "higher level" layer. ECS should
notify as he receives a query ("GET HTTP ..."), fill in some fields, and
then let the user create a string object that will be sent back to the
client. Not difficult at all.
As for binary data, unless we want to deal directly with them (that is,
build binary data on our own), a solution I've found is to look for such
files on the hard disk: this way, you may send images or sounds to the
client without having to open and handle them.

I.e. IF the client is looking for certain (known) data, THEN I'll build
those data; ELSE the client is looking for a file on my disc.

> I think it might be a good idea to implement at least the basics of
> protocols, since almost all TCP/IP protocols use the same structure: a
> one-line command, followed by a couple headers (which are attribute-value
> pairs separated by colons), exactly one blank line, and then content of a
> given length, which can be encoded or plain-text depending on the mime-type
> used.

Agreed! 

-- 
Ciao,
Dario
--
ADPM Synthesis sas - Torino
--
http://www.geocities.com/adpm99



  subject (prev) or (next) | time (prev) or (next) | author (prev) or (next) | view more subjects




Services provided by [NetBloc]®! NetBloc Solutions Inc.
Terms of use. Indexing software (c) 1999 Lin-De, Inc
.