Re: [Netatalk-devel] Return value for secondary reconnect by FPDisconnectOldSession

[didier <dga...@ma...>]

Hi,
Le mercredi 14 avril 2010 à 22:06 +0200, Frank Lahm a écrit :
> By incident I noticed that for a successfull FPDisconnectOldSession we
> return AFPERR_SESSCLOS (kFPSessClosed / -5022). The following patch
> introduces this:
> http://netatalk.cvs.sourceforge.net/viewvc/netatalk/netatalk/etc/afpd/auth.c?view=diff&r1=1.41&r2=1.42
> http://netatalk.cvs.sourceforge.net/viewvc/netatalk/netatalk/etc/afpd/auth.c?view=log#rev1.42
> 
> Before the patch we did return AFP_OK before which would mean a
> successfull primary reconnect. As we dont support that yet, we have to
> return something else then AFP_OK.  Do you remember who came you chose
> to return this value? Is it documented anywhere?  I can't find it at
> <http://tinyurl.com/y65sl99>.
I'd say it was whatever make the then uptodate OSX version happy
(10.2?), ie what didn't kill the client box. 

IIRC the specs and the actual OSX implementation differed.

I haven't look at them closely but there's mailing list messages around
this date (2003-03-10) which are related. AFPERR_SESSCLOS is either
coming from a long gone Apple doc or a capture done by Björn.
It's not in AFP 3.0, AFP 3.1 or AFP 3.2 specs.

> 
> Btw:
> I'm also thinking of how to implement primary reconnect. I might play
> a litte with switching afpd IPC from pipes to UNIX domain socket which
> would allow file descriptor passing. With this method the following
> would be possible:
> - client goes to sleep
> - server afpd process A idles
> - client awake and starts a new connection
> - afpd master forks a new child B for the connection
> - client calls FPDisconnectOldSession
> - B passed socket fd to afpd master and exits
> - master passed fd to A
> - a takes the fd and closes the old socket fd
Yes it makes a lot of sense but we need another signal or use select for
notifying process A. I'm not fond of using select or poll here.
  
Currently communication between children and master is a hack, it's a
one way pipe use by all children. It's ok because messages are small and
guaranteed to be atomic, sort of as I don't think we actually test that
the size is smaller than the OS limit for atomic write in a pipe.  

Of course it doesn't work for writing from the master to a child, at
least in a sane way.

Didier