(net-sessions)

newdep · Post by **newdep** » Mon Mar 08, 2004 4:57 pm

Hello Lutz,

This is a follow up on your (net-sessions) fix under 7507.

There is still a minor problem in the (net-sessions) display,
(see below the example).

Here is the problem description:

The First client that is connected to the server is remove direclty
from the (net-sessions) list after the first (net-send) of that client.
BUT the second client that connected needs 2x a (net-send) to be
deleted from the (net-sessions) list.

So only the FIRST client connected will be removed using 1x (net-send)
from the (net-sessions) list. Every second, third, etc client need 2x a (net-send) to be removed form the (net-sessions) list.

> (set 'server (net-listen 54001))
3
> (net-accept server) ** telnet to 54001 and hangup directly **
4
> (net-sessions)
(4 3)
> (net-accept server) ** telnet to 54001 and hangup directly **
5
> (net-sessions)
(5 4 3)
> (net-send 3 "abc")
nil
> (net-sessions)
(5 4)
> (net-send 4 "abc") ** First send non exsisting client
3
> (net-sessions)
(5 4)
> (net-send 4 "abc") ** second send to non excisting client
nil
> (net-sessions)
(5)
>

Hope you can reproduce it, the (net-receive ... ) nicly updates the (net-sessions) after 1x (net-receive ... ) is client is already gone.

Norman.

Lutz · Post by **Lutz** » Mon Mar 08, 2004 5:16 pm

I struggled with this when I did the first fix. There seems to be no way to find out if the client is down except for the second send, even a select() gives me an 'ok' the first time around. I depend on the return value of send() or on an exception generated by the socket stack to catch the 'client-dropped-connection' condition but it doesn't happen until the second send(). I wonder if this is inherent to the socket-stack drivers?

Anybody 'socket-expert' reading this?

Lutz

newdep · Post by **newdep** » Mon Mar 08, 2004 6:10 pm

Hello Lutz,

I had a look into your code and it all looks oke to me,
except for a detail perhpas, you know better them me :-)

Is the handling of FD_SET FD_ZERO different between a netSend netReceive?
I see an int writable() but dont see it anywhere in the code returned.

And a third thing was; my thoughts about the &timeout handling on linux, perhpas its too quick the first time and its oke but the second time the timeout
is different and it will return alsways 'nil?

Norman.

Lutz · Post by **Lutz** » Mon Mar 08, 2004 7:07 pm

thanks for the pointers, I will check ...

Lutz

Lutz · Post by **Lutz** » Mon Mar 08, 2004 8:22 pm

writable() was there from an earlier version, when I figured out it didn't do any good I took it out. This time I expanded it to handle exception flags too and used it in netSend(), but no change, the first send() always returns success and checking when the exception is really raised shows it doesn't happend until the second send(). Then I read this in the man pages about send():

"No indication of failure to deliver is implicit in a send. Locally detected errors are indicated by a return value of -1."

The first sentence seems to indicate that there isn't really a way to find out until after the send, except for local conditions. Perhaps this is why the first send() goes through? So it might be behaving correctly?

Lutz

newdep · Post by **newdep** » Mon Mar 08, 2004 9:15 pm

Hello Lutz,

Its correct that send does not check if remote hung up, but still the odd behaviour why the first time its direclty detected using send
and the second time only after the second send, looks like an extra loop somewhere or something not cleared after the first socket closure..

Im thinking, but never tried it befor ;-), what if your putting in an extra
send of ZERO bytes? befor sending the real data? I think that might do the
trick..

currious..let me know...
Norman.

Lutz · Post by **Lutz** » Mon Mar 08, 2004 9:36 pm

When a connection was open before, then the first send() will always return success, it seems that on a lower protocol level after that send flags are raised which then cause an exception/error on the next send(). Where did you observe the first send failing?

In socket communications, zeros are data just like any other bytes. Although many protocols are text based others send binary data containing zeros without encoding them, i.e.: FTP.

Lutz

newdep · Post by **newdep** » Mon Mar 08, 2004 9:48 pm

Hello Lutz,

I think i made a mistake ! i was sending data to the listener-socket.
So tested it again, send closed constantly after the second (net-send).
Which is correct...sorry for the mixup.

Norman.

Lutz · Post by **Lutz** » Mon Mar 08, 2004 9:52 pm

I am glad the net working routines got a good workout with you and we fixed the broken pipe problem. Perhaps your many 5-cent tips using the networking functions show some users that the TCP stuff is really not that difficult (... in newLISP ;-) )

Lutz

nigelbrown · Post by **nigelbrown** » Tue Mar 09, 2004 1:52 am

Hi Lutz,
Yes tcp is well integrated into newlisp -
One question 'though - seeing the lower level stuff is not visible without looking at source I'm asking how secure are the functions underlying newlisp tcp - one hears of buffer-overflow attacks etc - (I looked at nl-sock.c but don't know enough tcp in C to assess it from a security viewpoint)?

Nigel

newdep · Post by **newdep** » Tue Mar 09, 2004 10:46 am

Hello Nigel,

Actualy it all depends on what you expect from "security".

If newlisp would be "The" way of programming tcp
then Lutz would be a rich man ;-)

Norman.

nigelbrown · Post by **nigelbrown** » Tue Mar 09, 2004 12:27 pm

Hello Norman,
For 'security' I essentially mean that if I expose a newlisp socket to the internet for connection that the code handling the connections at a lower level to newlisp won't be trivially exploitable (I'd like to do a bibliographic manager that allows sharing of references along the lines of some commercial packages such as Biblioscape that include a http server to dish out refs to other users).
I wouldn't like it to be like a trojan just waiting to give access to the first port probing.
I realise that the newlisp lisp code is responsible for some authentication but I was wondering if the newlisp engine could be easily hijacked.
(If it can be don't give me the receipe here, of course).

Just wouldn't like to distribute an unsafe app or at least say it should only be used between trusted machines if that is best.

Lutz · Post by **Lutz** » Tue Mar 09, 2004 1:09 pm

As for bufferoverflows, I am shure you won't find any

Lutz

newdep · Post by **newdep** » Tue Mar 09, 2004 1:15 pm

Hello Nigel,

I understand your concern, the newlisp socket implementation is very
straightforward and does not contain, as far as i can see, odd extra's,
for basic communication over tcp and from what you can expect from
tcp communication, newlisp is good useable.

I will trust my applications to it...

Norman.