LNet installation error due to fastcgi.pp

[JD]

Hi all,

I can't install the LNet package. The installation aborts with a message saying an FPC unit has the same name as "fastcgi.pp"

I looked in the directories & I found two files named "fastcgi.pp" in two different directories listed below:

..lnet\lib\fastcgi.pp
..2.3.1\source\packages\fastcgi\src\fastcgi.pp

How do I correct this error?

I'm using Lazarus 0.9.29 FPC 2.3.1.

JD

[Crystal_Ra]

This truth. There is such problem.
Solve its was able only having puted stable version 0.9.28.2 fpc 2.2.4

[JD]

Solved the problem by installing the LNet package that was bundled with CodeTyphon. 

http://www.codetyphon.com

[Almindor]

lNet 0.6.3 shouldn't have these issues anymore

[JD]

That's right. The most recent version of LNet does not have these problems.

[JohnvdWaeter]

Speaking of lNet...

FCon : TLTCP

FCon.Count gives number of connections, right?

At first connection, it says 2 (?)

Further, when stresstesting (7 clients connecting / disconnecting at high rate) there is this moment that FCon.count becomes negative...  then it keeps on working, showing numbers like -1, -2, -3 etc and suddenly stops responding: connection refused by remote host

What does this mean?

tia!
John

[Almindor]

The count is right when it says "+1". It returns the number of sockets including the listening socket (docs say: This property specifies the total number of sockets in the connection.)

However the fact that it goes -1 or more is wrong. Can you send me a test case? Also, what OS/platform etc.

[JohnvdWaeter]

ok, problem solved.

lNet 0.6.4 fixed the negative count problem.

The freezing was not in the server, but in the client (winxp). Fast opening / closing of tcp-connections stalled. XP needs more time to release its sockets once connections are closed.

Vista and Win7 had no problem.

One final question: what does "ReuseAddress" mean? Could not find it in the doc_lnet.xml.

Thanks for testing!
John

[Almindor]

ReuseAddress is used to tell the server that the address/port you bind can be reused without waiting. this is useful when debugging for example and your server crashes, you would normaly have to wait for some time when the socket is in TIME_WAIT[2] state. With ReuseAddress if this happens you can simply start on same port again.

NOTE: that on some less sophisticated OSes (Windows older versions for example) it's a security risk (don't use in production)

[JohnvdWaeter]

Hi AlMindor,

I want to make sure my server does not get bloated with connections that are idle / not used for too long time.

Every client has a timestamp for last exchanged data. If the timestamp is longer then say about 3 minutes, I'd like to kill the connection.

So I iterate all connections and close them if the connection on that particular local port has been idle for too long:

Code: [Select]

fcon.iterreset;
 while fcon.iternext do
  if ThisSessionIsIdle (metacode)
   then fcon.iterator.disconnect(true);

This works, the connection is closed (as I can see on the connected client, which says "connection lost"), but the count-property of fcon does not decrease.

Is this the proper way of getting rid of idle connections?

btw if I use disconnect(false), the count-property decreases, but an OnReceive event is triggered for the socket that just got disconnected.

tia!
John

[Almindor]

The difference between disconnecting "true" and "false" in lNet is that with "true" you force a hard disconnect and lose any "on the way" data (you close the door both in and out). If you use false, you only close the "sending" side of the socket and wait for the other side to close theirs.

The reason why your sockets "linger" is due to no events happening. I think this is a bit of a logical oversight (although not critical). Basically, when a socket gets disconnected it turns "FDispose" flag to true. When the "event handler" finishes it's run it looks for all to-be-disposed sockets and frees them (this is when count goes down in TLTcp). I think you found a logical bug in the case that server-side user-event causes a hard disconnect on the socket. While the connection does go off it doesn't free the socket since no event took place and nobody actually found out about the dispose flag.

If you use "soft" disconnect, you actually cause an event to happen (the other side "affirms" your closing) and thus it works that way. I'll have to think about what to do with hard disconnects on eventers when called from the user.

So basically for now, use soft disconnects (they are the "proper" way from TCP standpoint too). The OnReceive you get is ok (you get the "recv = 0 => connection receive endpoint closed"). Since lNet doesn't use internal buffers, you must always call "recv" even if you're "receiving a disconnect"

I'll think about what to do with hard "user-side" disconnects (it's not as easy as it may sound actually, because I can't just free the socket at that time, and adding a new callback to the eventer seems hackish to me).

Currently hard disconnects are default but it's a compatibility thing (since before 0.5.x I used hard disconnects always). I'll switch to soft ones by default in 0.7.x.

[JohnvdWaeter]

Ok, I was afraid that the "soft" way would not work and that the socket would wait a long time before the (dead) client would respond to the closure.

However I did the following test:

1. Client connects to server
2. Pull the network plug from the client
3. After three minutes cleanup jumps in, issues a disconnect(false)
4. Connection goes down with a couple of error-events (of course) and count decreases ok (which means socket is freed)

Some background: it's all about a mobile application where I cannot rely on solid network connections. I normally use battery-friendly UDP for this, but there are mobile providers that insist on using a proxy so I had to introduce TCP.

Thanks for explanation ! :-)

John