[lazarus] Working with Sockets

[matooo at email.si]

Quoting 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.

Kylix in team? God, I've bought all of them and even v.3 doesn't measure up my
needs. But all of the examples in Kylix are made with threads, at least socket
c/s>everything components pack.

> 
> 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.
> 

My next app deadline is july(first beta) and october (final), so you can guess
which one I preffer. Suggested in that time.

> 
> >
> > >
> > > >
> > > > 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;
> 

ups, I missed that one. but I still wonder why jumps out in heavy threaded
console app. simple app works fine with this exception.

i guess i'll just work around my way. it's funny i tried two other methods that
get blown in heavy threading. in simple app they work just fine. unfortunatelly
simple apps is not what i need. on the other hand major tread doesn't cause any
problems with exceptions.

> 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.
> 

yep, 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.
> 

I did it already, thanks anyway I simply inherited TThreadedInetServer and
TThreadedInetSocket (and I left original intact so I've got both solutions) out
of sockets based in ssockets and everything is working like a charm. As I said
2.6 is what I'm waiting.

m.

> Michael.
> 
> _________________________________________________________________
>      To unsubscribe: mail lazarus-request at miraclec.com with
>                 "unsubscribe" as the Subject
>    archives at http://www.lazarus.freepascal.org/mailarchives
> 


-------------------
http://www.email.si