Menu
▾
▴
naviserver-devel
|
From: Zoran V. <zv...@ar...> - 2005-06-10 11:43:14
|
Hi! I'm in the process of cleaning up the code in order to re-enable Windows compilation. I've found several things we'd need to unify somehow: We have (until recently) had only TCP protocol support hence the calls like: Ns_SockBind Ns_SockListen etc. As of now, there are multiple other connection options supported (raw sockets, udp sockets, unix domain sockets). There are couple of places in the code where I see: Ns_SockBindUdp Ns_SockListenEx Ns_SockListenUdp Ns_SockListenRaw Ns_SockListenUnix I'd like to bring in some logic there. Therefore the proposal: All TCP related calls should stay as-is. We'd add additional calls to better identify what's being done: Ns_SockListenTcp (new, should be called by Ns_SocketListen) Ns_SockListenUdp (exists) Ns_SockListenRaw (exists) Ns_SockListenUnix (exists) Then: Ns_SockBindTcp (new, should be called by Ns_SocketBind) Ns_SockBindUdp (exists) Ns_SockBindRaw (new) Ns_SockBindUnix (new) In binder.c there are some calls which are only used withing the file hence we'd need to adjust the call interface to illustrate this: Ns_SockRaw - > SockRaw Also, the Ns_SockListenUnix is a combination of create + bind but unlike other pendants, does not honour the preboundUnix sockets. We should split this. Make the Ns_SockListenUnix actually honour prebound sockets (which it does not do now) and use internally the Ns_SockBindUnix to bind so it'd be on-pair with the TCP. All in all, this will not change the functionality but will *definitely* improve understanding and code maintenance. There are other places in sock.c which seem pretty odd like Ns_SockBind calls Ns_BindSock what is the reason of having those two (backward-compat?) I will like to cleanup this now. Are there any voices against or any other ideas? Cheers Zoran |
|
From: Vlad S. <vl...@cr...> - 2005-06-10 13:49:38
|
Looks like you already know what to do, so go ahead and cleanup that stuff. Zoran Vasiljevic wrote: > Hi! > > I'm in the process of cleaning up the code in order to > re-enable Windows compilation. > I've found several things we'd need to unify somehow: > > We have (until recently) had only TCP protocol support > hence the calls like: > > Ns_SockBind > Ns_SockListen > etc. > > As of now, there are multiple other connection options > supported (raw sockets, udp sockets, unix domain sockets). > There are couple of places in the code where I see: > > > Ns_SockBindUdp > > Ns_SockListenEx > Ns_SockListenUdp > Ns_SockListenRaw > Ns_SockListenUnix > > I'd like to bring in some logic there. Therefore the proposal: > > All TCP related calls should stay as-is. > > We'd add additional calls to better identify what's being done: > > Ns_SockListenTcp (new, should be called by Ns_SocketListen) > Ns_SockListenUdp (exists) > Ns_SockListenRaw (exists) > Ns_SockListenUnix (exists) > > Then: > > Ns_SockBindTcp (new, should be called by Ns_SocketBind) > Ns_SockBindUdp (exists) > Ns_SockBindRaw (new) > Ns_SockBindUnix (new) > > In binder.c there are some calls which are only used withing the > file hence we'd need to adjust the call interface to illustrate > this: > > Ns_SockRaw - > SockRaw > > Also, the Ns_SockListenUnix is a combination of create + bind > but unlike other pendants, does not honour the preboundUnix sockets. > We should split this. Make the Ns_SockListenUnix actually > honour prebound sockets (which it does not do now) and use > internally the Ns_SockBindUnix to bind so it'd be on-pair with > the TCP. > > All in all, this will not change the functionality but will > *definitely* improve understanding and code maintenance. > There are other places in sock.c which seem pretty odd like > > Ns_SockBind calls Ns_BindSock > > what is the reason of having those two (backward-compat?) > > I will like to cleanup this now. Are there any voices against > or any other ideas? > > Cheers > Zoran > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > shotput > a projector? How fast can you ride your desk chair down the office luge > track? > If you want to score the big prize, get to know the little guy. Play to > win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2005-06-10 14:41:23
|
Am 10.06.2005 um 15:46 schrieb Vlad Seryakov: > Looks like you already know what to do, so go ahead and cleanup > that stuff. > Vlad, Can you do me a favour and try the my new checkin of binder.c? I think I got it all right, but you never know until you test it. The usual TCP stuff works. I have not tried the rest (it should work though). Cheers Zoran |
|
From: Vlad S. <vl...@cr...> - 2005-06-10 15:09:47
|
It works i tested udp and icmp As for Unix sockets, on windows path will be different, on unix different but functionality will be there. Zoran Vasiljevic wrote: > > Am 10.06.2005 um 15:46 schrieb Vlad Seryakov: > >> Looks like you already know what to do, so go ahead and cleanup that >> stuff. >> > > Vlad, > > Can you do me a favour and try the my new checkin of binder.c? > I think I got it all right, but you never know until you > test it. The usual TCP stuff works. I have not tried the > rest (it should work though). > > Cheers > Zoran > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > shotput > a projector? How fast can you ride your desk chair down the office luge > track? > If you want to score the big prize, get to know the little guy. Play to > win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2005-06-10 15:24:27
|
Am 10.06.2005 um 17:09 schrieb Vlad Seryakov: > > As for Unix sockets, on windows path will be different, on unix > different but functionality will be there. Yes but the decision on wether the address is for a TCP or unix-domain socket is based on parsing the address string, right? So, on Unix, the unix-domain socket (AF_UNIX) would be something like: /path/to/file whereas on Windos it will/might be C:\path\to\file The parsing will just never discover that the above is the unix-domain socket and will go to parse the IP address instead (and fail). This is what I ment. Zoran |
|
From: Vlad S. <vl...@cr...> - 2005-06-10 15:59:27
|
We can check for slashes / and \ in the path, not just first character. This will work both on Unix and Windows. Zoran Vasiljevic wrote: > > Am 10.06.2005 um 17:09 schrieb Vlad Seryakov: > >> >> As for Unix sockets, on windows path will be different, on unix >> different but functionality will be there. > > > Yes but the decision on wether the address is for a TCP or unix-domain > socket is based on parsing the address string, right? > > So, on Unix, the unix-domain socket (AF_UNIX) would be > something like: > > /path/to/file > > whereas on Windos it will/might be > > C:\path\to\file > > The parsing will just never discover that the above > is the unix-domain socket and will go to parse the > IP address instead (and fail). This is what I ment. > > Zoran > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > shotput > a projector? How fast can you ride your desk chair down the office luge > track? > If you want to score the big prize, get to know the little guy. Play to > win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2005-06-10 16:05:31
|
Am 10.06.2005 um 17:58 schrieb Vlad Seryakov:
> We can check for slashes / and \ in the path, not just first
> character. This will work both on Unix and Windows.
>
Yes. There should be a call like:
bool NsLooksLikeUnixPath(char *path)
bool NsLooksLikeWindowsPath(char *path)
because you need to cover all sorts of weird formats.
Zoran
|
|
From: Vlad S. <vl...@cr...> - 2005-06-10 16:28:20
|
We can use Tcl_FSConvertToPathType or Tcl_FsStat Zoran Vasiljevic wrote: > > Am 10.06.2005 um 17:58 schrieb Vlad Seryakov: > >> We can check for slashes / and \ in the path, not just first >> character. This will work both on Unix and Windows. >> > > > Yes. There should be a call like: > > bool NsLooksLikeUnixPath(char *path) > bool NsLooksLikeWindowsPath(char *path) > > because you need to cover all sorts of weird formats. > > Zoran > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > shotput > a projector? How fast can you ride your desk chair down the office luge > track? > If you want to score the big prize, get to know the little guy. Play to > win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Zoran V. <zv...@ar...> - 2005-06-10 17:00:41
|
Am 10.06.2005 um 18:27 schrieb Vlad Seryakov:
> We can use
> Tcl_FSConvertToPathType or Tcl_FsStat
>
>
OK. So Tcl_FSConvertToPathType won't work since it will
accept anything that looks like a valid path, even the
192.168.1.1:8000, so this is not the way to go.
The Tcl_FSStat is more appealing since it will actualy
check the thing being a file. This is much better but
will break for people having the file called
192.168.1.1:8000 in the server's home directory :-)
I guess, you can't make all happy...
Also, I see (in driver.c:436)
drvPtr = firstDrvPtr;
while (drvPtr != NULL) {
if (drvPtr->bindaddr && drvPtr->bindaddr[0] == '/') {
drvPtr->opts |= NS_DRIVER_UNIX;
}
if (drvPtr->opts & NS_DRIVER_UDP) {
Here the decision is taken on examining the bind-address.
Couldn't we move this way down where the drvPtr->bindaddr
is actually assigned to and turn the drvPtr->opts there?
This would be more logical and easy to understand.
Zoran
|
|
From: Zoran V. <zv...@ar...> - 2005-06-10 16:34:18
|
Am 10.06.2005 um 18:27 schrieb Vlad Seryakov: > We can use > Tcl_FSConvertToPathType or Tcl_FsStat Yes. This could be a solution. I will look into that later today... Zoran |
|
From: Stephen D. <sd...@gm...> - 2005-06-10 16:56:28
|
On 6/10/05, Zoran Vasiljevic <zv...@ar...> wrote: >=20 > Am 10.06.2005 um 18:27 schrieb Vlad Seryakov: >=20 > > We can use > > Tcl_FSConvertToPathType or Tcl_FsStat >=20 > Yes. This could be a solution. I will > look into that later today... Ns_PathIsAbsolute() ? |
|
From: Vlad S. <vl...@cr...> - 2005-06-10 17:10:42
|
Good call, i will move. Until we find good way for determining file
paths, i will check for unix style for now.
Also, do we want to keep old style virtual hosting by loading nssock
globally. I've never used it and it is so
inconvenient. The code is in the DriverInit. Or we can convert it as i
offered a while ago to be able do host mapping in any loaded nssock
driver without need to load nssock globally.
>
> Also, I see (in driver.c:436)
>
> drvPtr = firstDrvPtr;
> while (drvPtr != NULL) {
> if (drvPtr->bindaddr && drvPtr->bindaddr[0] == '/') {
> drvPtr->opts |= NS_DRIVER_UNIX;
> }
> if (drvPtr->opts & NS_DRIVER_UDP) {
>
> Here the decision is taken on examining the bind-address.
> Couldn't we move this way down where the drvPtr->bindaddr
> is actually assigned to and turn the drvPtr->opts there?
> This would be more logical and easy to understand.
>
> Zoran
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games. How far can you
> shotput
> a projector? How fast can you ride your desk chair down the office luge
> track?
> If you want to score the big prize, get to know the little guy. Play to
> win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
--
Vlad Seryakov
571 262-8608 office
vl...@cr...
http://www.crystalballinc.com/vlad/
|
|
From: Zoran V. <zv...@ar...> - 2005-06-10 17:17:59
|
Am 10.06.2005 um 19:09 schrieb Vlad Seryakov: > Also, do we want to keep old style virtual hosting by loading > nssock globally. I've never used it and it is so > inconvenient. The code is in the DriverInit. Or we can convert it > as i offered a while ago to be able do host mapping in any loaded > nssock driver without need to load nssock globally. > Uh... I can't answer immediately but I'm afraid it will hit us in the back. I'd rather stay with the global nssock until I check out what would that mean for our app. Zoran |
|
From: Stephen D. <sd...@gm...> - 2005-06-10 18:50:52
|
I'd like to keep this as is for the moment.
On 6/10/05, Vlad Seryakov <vl...@cr...> wrote:
> Good call, i will move. Until we find good way for determining file
> paths, i will check for unix style for now.
>=20
> Also, do we want to keep old style virtual hosting by loading nssock
> globally. I've never used it and it is so
> inconvenient. The code is in the DriverInit. Or we can convert it as i
> offered a while ago to be able do host mapping in any loaded nssock
> driver without need to load nssock globally.
>=20
> >
> > Also, I see (in driver.c:436)
> >
> > drvPtr =3D firstDrvPtr;
> > while (drvPtr !=3D NULL) {
> > if (drvPtr->bindaddr && drvPtr->bindaddr[0] =3D=3D '/') {
> > drvPtr->opts |=3D NS_DRIVER_UNIX;
> > }
> > if (drvPtr->opts & NS_DRIVER_UDP) {
> >
> > Here the decision is taken on examining the bind-address.
> > Couldn't we move this way down where the drvPtr->bindaddr
> > is actually assigned to and turn the drvPtr->opts there?
> > This would be more logical and easy to understand.
> >
> > Zoran
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you
> > shotput
> > a projector? How fast can you ride your desk chair down the office luge
> > track?
> > If you want to score the big prize, get to know the little guy. Play t=
o
> > win an NEC 61" plasma display: http://www.necitguy.com/?r=3D20
> > _______________________________________________
> > naviserver-devel mailing list
> > nav...@li...
> > https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>=20
> --
> Vlad Seryakov
> 571 262-8608 office
> vl...@cr...
> http://www.crystalballinc.com/vlad/
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games. How far can you sho=
tput
> a projector? How fast can you ride your desk chair down the office luge t=
rack?
> If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=3D20
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
|
|
From: Stephen D. <sd...@gm...> - 2005-06-13 07:37:24
|
On 6/10/05, Zoran Vasiljevic <zv...@ar...> wrote: > Hi! >=20 > I'm in the process of cleaning up the code in order to > re-enable Windows compilation. > I've found several things we'd need to unify somehow: >=20 > We have (until recently) had only TCP protocol support > hence the calls like: >=20 > Ns_SockBind > Ns_SockListen > etc. >=20 > As of now, there are multiple other connection options > supported (raw sockets, udp sockets, unix domain sockets). > There are couple of places in the code where I see: >=20 >=20 > Ns_SockBindUdp >=20 > Ns_SockListenEx > Ns_SockListenUdp > Ns_SockListenRaw > Ns_SockListenUnix >=20 > I'd like to bring in some logic there. Therefore the proposal: >=20 > All TCP related calls should stay as-is. >=20 > We'd add additional calls to better identify what's being done: >=20 > Ns_SockListenTcp (new, should be called by Ns_SocketListen) > Ns_SockListenUdp (exists) > Ns_SockListenRaw (exists) > Ns_SockListenUnix (exists) Ns_SockListenTcp() should probably replace Ns_SockListenEx() with it's backlog parameter? The passed backlog should be checked, and if it's < 1, use the default from the config file. If this is the new recommended way to listen on sockets, I'd update all callers of the old Ns_SockListen(Ex) functions. People will cut 'n paste old code and continue the confusion. > Then: >=20 > Ns_SockBindTcp (new, should be called by Ns_SocketBind) > Ns_SockBindUdp (exists) > Ns_SockBindRaw (new) > Ns_SockBindUnix (new) > > In binder.c there are some calls which are only used withing the > file hence we'd need to adjust the call interface to illustrate > this: >=20 > Ns_SockRaw - > SockRaw >=20 > Also, the Ns_SockListenUnix is a combination of create + bind > but unlike other pendants, does not honour the preboundUnix sockets. > We should split this. Make the Ns_SockListenUnix actually > honour prebound sockets (which it does not do now) and use > internally the Ns_SockBindUnix to bind so it'd be on-pair with > the TCP. Hmm, Ns_SockListenUnix() doesn't actually call listen(). Is this right? Also, is a backlog parameter appropraite here, as in Ns_SockListenEx()? > All in all, this will not change the functionality but will > *definitely* improve understanding and code maintenance. > There are other places in sock.c which seem pretty odd like >=20 > Ns_SockBind calls Ns_BindSock >=20 > what is the reason of having those two (backward-compat?) You can decalare Ns_BindSock() NS_GNUC_DEPRECATED and no one else need be confused :-) > I will like to cleanup this now. Are there any voices against > or any other ideas? >=20 > Cheers > Zoran |
|
From: Zoran V. <zv...@ar...> - 2005-06-13 08:25:32
|
Am 13.06.2005 um 09:37 schrieb Stephen Deasey:
>
> Ns_SockListenTcp() should probably replace Ns_SockListenEx() with it's
> backlog parameter? The passed backlog should be checked, and if it's
> < 1, use the default from the config file.
>
> If this is the new recommended way to listen on sockets, I'd update
> all callers of the old Ns_SockListen(Ex) functions. People will cut
> 'n paste old code and continue the confusion.
Well, I have left the Ns_SockListenEx() untouched. We might rename
it to Ns_SockListenTcp() to be more consistent but I did not want
to do that yet because I do not know what side-effects this may
have.
>
> Hmm, Ns_SockListenUnix() doesn't actually call listen(). Is this
> right? Also, is a backlog parameter appropraite here, as in
> Ns_SockListenEx()?
No, it does not. It just binds.
As well as the raw sockets; Ns_SockBindRow does not bind.
It just creates the socket.
I did not want to add complete confusion so I followed the
TCP way:
ListenXXX
BindXXX
where XXX = Unix, Raw
and
Listen
Bind
is reserved for TCP. The only real exception is Ns_SocketListenEx
which just adds one additional (backlog) parameter.
Admitently, some calls are real misnomers as I already documented
in the funciton comment:
*
* Ns_SockBindRaw --
*
* Create a raw socket. It does not bind, hence the call name
* is not entirely correct but is on-pair with other types of
* sockets (udp, tcp, unix).
*
In the process of cleanup, we might rectify/improve this and
give the calls more meaningful names.
>
>
> You can decalare Ns_BindSock() NS_GNUC_DEPRECATED and no one else need
> be confused :-)
This is OK. I will do that.
Zoran
|
|
From: Stephen D. <sd...@gm...> - 2005-06-14 07:45:47
|
On 6/13/05, Zoran Vasiljevic <zv...@ar...> wrote: >=20 > Am 13.06.2005 um 09:37 schrieb Stephen Deasey: >=20 > > > > Ns_SockListenTcp() should probably replace Ns_SockListenEx() with it's > > backlog parameter? The passed backlog should be checked, and if it's > > < 1, use the default from the config file. > > > > If this is the new recommended way to listen on sockets, I'd update > > all callers of the old Ns_SockListen(Ex) functions. People will cut > > 'n paste old code and continue the confusion. >=20 > Well, I have left the Ns_SockListenEx() untouched. We might rename > it to Ns_SockListenTcp() to be more consistent but I did not want > to do that yet because I do not know what side-effects this may > have. >=20 > > > > Hmm, Ns_SockListenUnix() doesn't actually call listen(). Is this > > right? Also, is a backlog parameter appropraite here, as in > > Ns_SockListenEx()? >=20 > No, it does not. It just binds. > As well as the raw sockets; Ns_SockBindRow does not bind. > It just creates the socket. I don't understand why listen() is not called. You have to do this in order to receive connections, right? |
|
From: Zoran V. <zv...@ar...> - 2005-06-14 07:50:21
|
Am 14.06.2005 um 09:45 schrieb Stephen Deasey: > I don't understand why listen() is not called. You have to do this in > order to receive connections, right? Eh... Vlad should answer that :-) All I did was cosmetically cleaning up the code w/o actually going into the functionality. I did not want to change anything functionality-wise until he looks over it. Zoran |
|
From: Vlad S. <vl...@cr...> - 2005-06-14 13:34:25
|
Yes, i missed that which means i never tried unix domain sockets yet Zoran Vasiljevic wrote: > > Am 14.06.2005 um 09:45 schrieb Stephen Deasey: > >> I don't understand why listen() is not called. You have to do this in >> order to receive connections, right? > > > > Eh... Vlad should answer that :-) > > All I did was cosmetically cleaning up the code w/o actually > going into the functionality. I did not want to change anything > functionality-wise until he looks over it. > > Zoran > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > shotput > a projector? How fast can you ride your desk chair down the office luge > track? > If you want to score the big prize, get to know the little guy. Play to > win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > naviserver-devel mailing list > nav...@li... > https://lists.sourceforge.net/lists/listinfo/naviserver-devel -- Vlad Seryakov 571 262-8608 office vl...@cr... http://www.crystalballinc.com/vlad/ |
|
From: Stephen D. <sd...@gm...> - 2005-06-15 07:21:02
|
On 6/13/05, Zoran Vasiljevic <zv...@ar...> wrote: >=20 > Am 13.06.2005 um 09:37 schrieb Stephen Deasey: >=20 > > > > Ns_SockListenTcp() should probably replace Ns_SockListenEx() with it's > > backlog parameter? The passed backlog should be checked, and if it's > > < 1, use the default from the config file. > > > > If this is the new recommended way to listen on sockets, I'd update > > all callers of the old Ns_SockListen(Ex) functions. People will cut > > 'n paste old code and continue the confusion. >=20 > Well, I have left the Ns_SockListenEx() untouched. We might rename > it to Ns_SockListenTcp() to be more consistent but I did not want > to do that yet because I do not know what side-effects this may > have. >=20 > > > > Hmm, Ns_SockListenUnix() doesn't actually call listen(). Is this > > right? Also, is a backlog parameter appropraite here, as in > > Ns_SockListenEx()? >=20 > No, it does not. It just binds. > As well as the raw sockets; Ns_SockBindRow does not bind. > It just creates the socket. >=20 > I did not want to add complete confusion so I followed the > TCP way: >=20 > ListenXXX > BindXXX >=20 > where XXX =3D Unix, Raw >=20 > and >=20 > Listen > Bind >=20 > is reserved for TCP. The only real exception is Ns_SocketListenEx > which just adds one additional (backlog) parameter. >=20 > Admitently, some calls are real misnomers as I already documented > in the funciton comment: >=20 > * > * Ns_SockBindRaw -- > * > * Create a raw socket. It does not bind, hence the call name > * is not entirely correct but is on-pair with other types of > * sockets (udp, tcp, unix). > * >=20 > In the process of cleanup, we might rectify/improve this and > give the calls more meaningful names. Hmm, I don't think this naming scheme is clarifying things. The situation is that Ns_SockListenRaw() does not in fact listen. It call down to Ns_SockBindRaw() which does not in fact bind... I think we have to assume that programmers who need to use UDP and raw sockets have some idea of how they work. Pretending that they listen and/or bind is probably just going to confuse them. Isn't bind() the privileged call here, not listen? I think the hash look-up needs to be pushed down into the bind calls. Then ListenUdp and BindRaw can be dropped. And ListenUnix still needs a backlog arg... Oh, and Ns_SockListenUnix(char *path) is yet another thing that won't work with the Tcl VFS... :-) |
|
From: Zoran V. <zv...@ar...> - 2005-06-15 07:39:37
|
Am 15.06.2005 um 09:20 schrieb Stephen Deasey:
>>
>> In the process of cleanup, we might rectify/improve this and
>> give the calls more meaningful names.
>>
>
>
> Hmm, I don't think this naming scheme is clarifying things. The
> situation is that Ns_SockListenRaw() does not in fact listen. It call
> down to Ns_SockBindRaw() which does not in fact bind...
As I already said above... it is not very meaningful but it follows
the
first bind, then listen
for *all* types of sockets. So no matter what socket you use, you
might want to bind to the socket (yes, privlieged operation)
then listen. The current listen calls are already clever to
honour the pre-binded sockets and use them, binding only
when needed. So, technically speaking you do not need the
explicit bind, or?
>
> I think we have to assume that programmers who need to use UDP and raw
> sockets have some idea of how they work. Pretending that they listen
> and/or bind is probably just going to confuse them.
If you look at it from that angle, then yes.
>
> Isn't bind() the privileged call here, not listen? I think the hash
> look-up needs to be pushed down into the bind calls. Then ListenUdp
> and BindRaw can be dropped. And ListenUnix still needs a backlog
> arg...
>
I will check this (havent thought much about the real functionality
while unifiying call-names, as said before).
> Oh, and Ns_SockListenUnix(char *path) is yet another thing that won't
> work with the Tcl VFS... :-)
I have no problem with that. The fact is that most people also need temp
directories and those must be somewhere on the filesystems, like pipes,
unix-domain sockets and stuff like that. The VFS should really aid in
getting the software distribution simpler to a greater extent. The
ultimative is to pack everything (I mean *everything*) into a monolit
file and distribute this file only (starkit). But, during the *runtime*
things are going to be done in the native filesystem (the example avove,
the temporary directory, loading shared librarries, etc etc).
So, I'm heaading slowly towards "being able to pack everything". One of
the steps I see on the road ahead is "package req NaviServer" which
would
make us just-another-tcl-extension which everybody could use.
Zoran
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X