Subject: From: Date:

RE: [ECS] Socket Connection Ingo Pakleppa Sun, 07 Jan 2001 21:39:40 -0800

---

Actually, I don't really have any need for it in the first place, but was 
thinking that pure socket connections are actually very unusual. They are 
certainly possible, but almost all TCP/IP connections in the "real world" 
involve some kind of high-level protocol, and usually standard ones such as 
HTTP or FTP. Without knowing what you were planning to do with it, I just 
wanted to suggest something that I believe would be more helpful.

Incidentally, if you are talking about protocol-independent socket requests 
as a general feature (rather than for one specific application), outbound 
traffic is only half of what you'd need; you should also be able to handle 
inbound traffic (i.e., ECS acting as a server). I suspect that this may 
actually be more useful, but  it's also significantly more complicated than 
with serial-line traffic because you can have more than one concurrent 
connection and need to be able to sort out which connection sent which 
byte. Again, I don't have any need for this feature right now, but am 
looking at it from a software engineering standpoint.

Ingo

At 09:36 PM 1/7/2001 -0800, Nathan Brown wrote:
>My original request was targeted more at being able to write additional
>services that ECS could connect to and make requests from, NOT for high
>level protocol requests.  If you want to put higher level protocols into
>ECS that would be a different need entirely that to be able to make
>protocol independent socket requests.  Perhaps it would help if you
>detailed your need for this type of enhancement.
>
>NB
>
>-----Original Message-----
>From: Ingo Pakleppa [mailto:ipakleppa@yahoo.com]
>Sent: Sunday, January 07, 2001 7:13 PM
>To: ecs-list@netbloc.com
>Subject: Re: [ECS] Socket Connection
>
>
>At 11:02 PM 1/7/2001 +0100, Dario Greggio wrote:
> >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.
>
>Well, the point I was trying to make is that quite often, if you just
>open
>a binary file and send it, the protocol won't be able to handle it. You
>may
>have to first translate it into ASCII characters using something like
>Base64 encoding or UUEncode.
>
>Of course I may well be quite off base on this. Personally, I have no
>need
>for TCP/IP; I'm just looking at the request from a software engineering
>standpoint.
>
>Ingo

---