(net-sessions)

[newdep]

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]

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]

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]

thanks for the pointers, I will check ...



Lutz

[Lutz]

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]

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]

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]

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]

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]

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]

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]

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]

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



Lutz

[newdep]

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.