[lazarus] Working with Sockets

[Michael.VanCanneyt at Wisa.be]

On Sun, 8 Dec 2002 matooo at email.si wrote:

> Quoting Michael Van Canneyt <michael.vancanneyt at wisa.be>:
>
> >
> >
> > On Sun, 8 Dec 2002 matooo at email.si wrote:
> >
> > > Quoting Anders Jensen <outdoors at tiscali.no>:
> > >
> > > > Har anyone any knowledge about working with sockets in Lazarus?
> > > > I`m tearing my hair off here (and has little of it as it is) ,
> > trying
> > > > to make
> > > > a simple little p2p chat-client on SuSE 8.0, nuthin seems to work
> > using
> > > > the sockets-unit in FPC... or maybe I`m just doin it all wrong
> > (very
> > > > possible)
> > > >
> > > > AJ
> > > >
> > >
> > > Problem is larger in some ways than it seems. First major problem is
> > that
> > > sockets  in ssockets unit don't respect kernel specifications for this
> > kind of
> > > communications.
> >
> > Well, why don't you communicate what the problems are, maybe we can
> > solve them ?
> >
>
> So, I did.
> But last time I was making a suggestion, there was all talk and talk and talk.
> But nobody did something. Ok, I did what I needed but you obviously weren't
> prepared to take it as I suggested, so I completed my suggestion for my use and
> you probably did yours I really don't know because until week ago I was still
> working with the same version as almost a year ago. Now that I'm finished with
> my project I can finally move on (I really hated new delphi version, so I never
> trust nobody to swap the tool I'm using between a project in work). But what I
> saw was two things, except Interfaces, everything worked out fine, great work
> every time delphi got upgraded I almost suffered mental attack.
> And some bugs that stayed the same as I noted "in my special conditions".
>
> >
> > >
> > > Basically,
> > > 1. In linux accept (there is no check mode, accept just waits until it
> > gets
> > > result) should be run in a thread.
> > > 2. When accept is invoked another thread should be invoked which
> > creates a
> > > socket and this socket communicates with a client.
> > > To conclude, No multithreading, no fun
> >
> >
> > This is not needed when running asynchronous IO. There are examples of a
> > webserver
> > written in FPC using asynchronous IO. Threadprogramming makes some
> > things easier,
> > but is not required at all.
> >
>
> Read the book "The Linux Kernel". It explains all. No threading one connection
> or you're going the wrong way against the principles of suggested kernel
> programming.

Read 'Advanced programming in the UNIX environment' by W.R. Stevens
and you'll find reasons to do the opposite. Look, I'm not saying that thread
programming is wrong. It is one way. Asynch programming is another way,
avoiding threads. Threads solve some issues, but they do raise other issues
in programs. If you're a german speaker, I suggest you buy the 'Kylix in Team'
book; there I show different approaches to programming linux sockets, with and
without threads.

Also, don't forget that the Linux kernel (except the new development kernel)
has no real threading, A thread from the kernelpoint of view is just a process
sharing it's data segment with another process. No special thread
optimizations or so exist. I don't say anything about the latest
development kernels, I know that special thread functions have been
implemented there. But the stable kernel has nothing for threads.


>
> >
> > >
> > > I'm making a CS socket communication and I've succesfully made all
> > the
> > > components I need, which I would be glade to contribute (as well as
> > few bugs,
> > > more likely security bugs and their solutions). There's just a fact
> > that sockets
> > > are not 100% tested and I'm still making a TInetJob queue which takes
> > care if
> > > there are more then one job for the same communication eg. copying
> > multiple
> > > files in different directions. They will be completed in friday
> > (that's my
> > > deadline for the project (mostly lazarus and bash cooperation) I've
> > been working
> > > last 7 months and communication is the last part of it). Just tell me
> > where to
> > > drop them or whom to send if you're interested. But I've corrected
> > only
> > > TInetSocket not TUnixSocket, which can just follow my example with
> > Inet.
> >
> > You can send patches to me or to sebastian guenther
> > (sebastian.guenther at freepascal.org)
> >
>
> So I will, but my solution is heavy on threading already in motion. If that's no
> problem? My guess after reading your response is that you don't like that.

The solution should not assume anything about the way the things are
programmed other than that it uses classes, streams and exceptions.
The ssockets implementation can and should be used with or without threads.

> > > And explanation for security bugs.
> > > There are some problems in your components, mainly involving forceably
> > exiting
> > > software after a bug. I understand that's common in Windows
> > environment but Unix
> > > isn't like that. Sockets have that one too. But there is a nicer
> > example.
> > >
> > > bug (XML#1)
> > > 1. Take xml file
> > > 2. Add some garbage at the end
> > > 3. Try to read it
> > > 4. Program exits with error
> >
> > You should put a try/except block around it of course. this is common
> > programming
> > technique in Object Pascal.
> >
>
> So, I should???? heh, ???

Yes.

> in XMLReader.ExpectProlog that function throws out if
> there is something after the end, and notify nobody that it is unsuccessful.
> Component is not assigned and result is not nil, a bug I guess.
>
> There is no exceptions in XMLRead, at least I haven't seen them. And if I
> produce exception I finally get a load of unspecied allocated memory.

I suggest you check the code again, line 138:

procedure TXMLReader.RaiseExc(descr: String);
var
  apos: PChar;
  x, y: Integer;
begin
  // find out the line in which the error occured
  apos := BufStart;
  x := 1;
  y := 1;
  while apos < buf do begin
    if apos[0] = #10 then begin
      Inc(y);
      x := 1;
    end else
      Inc(x);
    Inc(apos);
  end;
  raise EXMLReadError.Create('In ' + Filename + ' (line ' + IntToStr(y) + ' pos     IntToStr(x) + '): ' + descr);
end;

the XMLReader.ExpectProlog you refer to, calls this method.

About unallocated memory: Programs that use exceptions should always
cater for exceptions. This includes releasing memory when an exception
occurs.

>
> Problem is "not all xml files get written by your component, beacuse if file is
> written with it it's complying with xml specifications", make one from a script
> or some other language that produces xml file with a bug.
>
> So, is it a bug or not??? You decide.

There is no 'bug'; it just doesn't work as you expect, I guess.

>
> > >
> > > bug (sockets#1)
> > > 1. Client tryes to make communication that doesn't exist
> > > 2. Program invokes error
> > > 3. Read 5 in XML bug
> >
> > See same solution.
> >
>
>   FConnected := Sockets.Connect(ASocket, addr, sizeof(addr));
> //  If not Sockets.Connect(ASocket, addr, sizeof(addr)) then
> //    raise ESocketError.Create(seConnectFailed, [Format('%s:%d',[FHost, FPort])]);
>
> and tell me why there should be exception on trying to connect. Nicer way,
> connect runs in thread and tryes to login. Cancel thread cancel connection, or
> too many tryouts cancels connection. Bug occurs in a simple console application,
> in gui application your exception throws out dialog with a message, in console,
> guess what whole software gets thrown out, exception or not, at least for me.
>

I'm not saying that the connect method cannot be improved. We can add a
handler that gets called when the connect fails and throw the exception
if there is no such handler, but we should not assume threads. If this
doesn't fit your specific needs, then you'll have to find another solution.

Michael.