Jabber 2.1 SVN win32 native Windows build with service support

Hi,

You may remember me, two years ago I've posted patches for
jabberd 2.0
and Visual Studio 2003 .NET. Since then many things have
change in the
jabberd2 code, and it has moved to SVN repository.

Please find following guide on how to use recent jabberd2
version on
Windows:

http:/
/www.nanoant.com/projects/jabberd2-win32

I've made this port mainly because we are forced to stick to
Windows
servers at my office, however we are willing to use internal
Jabber/XMPP
server.

This port was made with Visual Studio 2005 SP1.

I'm providing ready to use binaries with MySQL & SQLite
support, as well
with native Windows NTLogon auth module.

All services also have win32 native service support. To
install service
run i.e.: "router -I", or "router -U" to
uninstall.

You will get "jabberd2router" (Jabber 2 Router)
service installed.

By default it is installed for manual run.
All .xml config files will be read from the path the files
reside.

You can also run them normally in command line.

I've already asked maintainers & developers of jabberd2
if it was
possible to add those patches to official SVN (CVS then).
But the
discussion ended up with no result.

So now, if it is possible to apply those patches to SVN it
would be
great, cause jabberd2 may gain many more Windows users,
especially those
running Windows servers at their companies.

I've tested those changes, and they are non-invasive for
other build
(autoconf based), so they are *NOT* changing behaviour of
jabberd2 on
other platforms.

Most of the changes are JABBERD2_API defines and prefixing
that is
required on win32 to build DLLs, since we really need to
mark exported
functions.

Other changes are related to mio & WinSock and the fact
that on Windows
socket file descriptors don't start from 1, but usually from
1xxx,
therefore "select" 1024 maximum descriptors is
simply not enough.

Last changes are native service implementation at
"util" & "jsignal.c".

Waiting for your remarks.

I'd gladly appreciate also if you could link somewhere at
http://jabberd2.xiaoka.co
m/ to my site, so all Windows users will have
opportunity to use this great server software on their
platform.

Best regards,
-- 
Adam Strzelecki (also Miranda-IM developer)

P.S. If you will put those changes into SVN I'm willing to
maintain all
MSVC related stuff at SVN as well. I may think also of
producing some
Windows jabberd2 automated installer with NSIS, that will
guide the
administrator on installing the jabberd2 server with
specific options.
What do you think?

P.P.S. As I'm one of Miranda-IM developers I'm really fed up
with all
those commercial protocols like ICQ, AIM, etc.. and I see
that XMPP is
only change to push IM into the future, so may happen if we
can
popularize OpenSource jabberd2 server also on Windows
platforms.

_______________________________________________
jabberd mailing list
jabberdjabberstudio.org
http:
//mail.jabber.org/mailman/listinfo/jabberd

On Tue, 22 May 2007 21:26:03 +0200, Adam Strzelecki wrote:
> Other changes are related to mio & WinSock and the
fact that on Windows
> socket file descriptors don't start from 1, but usually
from 1xxx,
> therefore "select" 1024 maximum descriptors
is simply not enough.

Note that the mio interface doesn't assume that file/socket
descriptors
start from 1 any more, only the mio_select implementation
makes that
assumption. Therefore it might not be the best idea to base
the Windows
implementation on the existing mio_select implementation. Or
to put it
another way: I don't like the lowfd "hack" for
Windows. I would assume that
this could be solved in a much cleaner way by slightly
reworking the
existing select implementation.

BTW, most of the #ifdef _MSC_VER code appears to be Win32
specific and not
MS-VC specific and should therefore probably be #ifdef WIN32
instead...


Christof

-- 

http://cmeerw.org           
                  sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at
cmeerw.org
_______________________________________________
jabberd mailing list
jabberdjabberstudio.org
http:
//mail.jabber.org/mailman/listinfo/jabberd

On wto, 2007-05-22 at 21:26 +0200, Adam Strzelecki wrote:
> So now, if it is possible to apply those patches to SVN
it would be
> great, cause jabberd2 may gain many more Windows users,
especially
> those
> running Windows servers at their companies.

Well... As long as these are non invasive for other
platforms, it surely
is possible.


> Waiting for your remarks.

Please contact me off-list on JID: smokuxiaoka.com for full Trac and
SVN access.


> I'd gladly appreciate also if you could link somewhere
at
> http://jabberd2.xiaoka.co
m/ to my site, so all Windows users will have
> opportunity to use this great server software on their
platform.

Done.


-- 
Tomasz Sterna
Xiaoka Grp.  http://www.xiaoka.com/

_______________________________________________
jabberd mailing list
jabberdjabberstudio.org
http:
//mail.jabber.org/mailman/listinfo/jabberd

Hi Christof,

> Note that the mio interface doesn't assume that
file/socket descriptors
> start from 1 any more, only the mio_select
implementation makes that
> assumption. Therefore it might not be the best idea to
base the Windows
> implementation on the existing mio_select
implementation. Or to put it
> another way: I don't like the lowfd "hack"
for Windows. I would assume that
> this could be solved in a much cleaner way by slightly
reworking the
> existing select implementation.

Sure. I was thinking of mio_select.h actually, which is the
only
sensible implementation on Win32, and here actually I've
added "lowfd"
as well next to "highfd".

But I had to change also the calls to the mio_new(1024) that
was
previously hadcoded into mio_new(MIO_MAXFD), that's defined
to 16k on
Windows and 1024 (as before) on other platforms.

> BTW, most of the #ifdef _MSC_VER code appears to be
Win32 specific and not
> MS-VC specific and should therefore probably be #ifdef
WIN32 instead...

You're right, that is more sensible, and this is what I got
at first
time. My intent was not to hurt other platforms and
compilers though, so
I've changed to _MSC_VER. But I gonna revert back to #ifdef
_WIN32, also
change all #ifdef WIN32 to #ifdef _WIN32, coz _WIN32 is the
only one
defined by all Windows compilers, while WIN32 is defined
only by GCC on
Win32, not MSVC (while it may be defined somewhere later on
the project).

Here's a little test:

------------------------------ CUT
----------------------------------
#define __QUOTE(x)		#x
#define QUOTE(x)		__QUOTE(x)

#ifdef _WIN32
	#define S_WIN32		" _WIN32"
#else
	#define S_WIN32
#endif

#ifdef WIN32
	#define SWIN32		" WIN32"
#else
	#define SWIN32
#endif

#ifdef _MSC_VER
	#define S_MSC_VER	" _MSC_VER=" QUOTE(_MSC_VER)
#else
	#define S_MSC_VER
#endif

#ifdef __GNUC__
	#define S__GNUC__	" __GNUC__=" QUOTE(__GNUC__)
#else
	#define S__GNUC__
#endif

#include <stdio.h>

int main(int argc, char ** argv[])
{
	printf(S_WIN32 SWIN32 S_MSC_VER S__GNUC__ "n");
	return 0;
}
------------------------------ CUT
----------------------------------

On MSVC we got: _WIN32 _MSC_VER=1400

On MinGW we got: _WIN32 WIN32 __GNUC__=3

On Linux we got: __GNUC__=3

(if we use GCC ver. 3.x)

Didn't test on Intel CC ;P

Regards,
-- 
Adam
_______________________________________________
jabberd mailing list
jabberdjabberstudio.org
http:
//mail.jabber.org/mailman/listinfo/jabberd

On Wed, 23 May 2007 12:32:31 +0200, Adam Strzelecki wrote:
> But I had to change also the calls to the mio_new(1024)
that was
> previously hadcoded into mio_new(MIO_MAXFD), that's
defined to 16k on
> Windows and 1024 (as before) on other platforms.

The intention of the parameter to mio_new is, if the mio
implementation is
done correctly, to specify the number of file descriptors
supported (and not
the maximum value of the file descriptor as with the current
mio_select
implementation). And I would assume that 1024 file
descriptors would be more
than enough on all platforms.

BTW, I just noticed that max_fds is only configurable for
c2s and router,
but not s2s. What's the reason to have it configurable for
the router (isn't
the number of file descriptors the router uses usually quite
limited
anyway)? Wouldn't it make more sense to have it configurable
for s2s
instead?


Christof

-- 

http://cmeerw.org           
                  sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at
cmeerw.org
_______________________________________________
jabberd mailing list
jabberdjabberstudio.org
http:
//mail.jabber.org/mailman/listinfo/jabberd

Christof,

> The intention of the parameter to mio_new is, if the
mio implementation is
> done correctly, to specify the number of file
descriptors supported (and not
> the maximum value of the file descriptor as with the
current mio_select
> implementation). And I would assume that 1024 file
descriptors would be more
> than enough on all platforms.

Yeah, I'm aware of that. But I didn't want to change the way
mio behaves
on other platforms... rather make it work on Windows. Just
wanted the
code to be the same except places where #ifdef _WIN goes.

Still I'll have to find a good solution for doing
"select" on windows
without wasting all those unused range of descriptors.

> BTW, I just noticed that max_fds is only configurable
for c2s and router,
> but not s2s. What's the reason to have it configurable
for the router (isn't
> the number of file descriptors the router uses usually
quite limited
> anyway)? Wouldn't it make more sense to have it
configurable for s2s
> instead?

Hmmm... yup that's indeed bizarre. I think you're right as
s2s and c2s
are only services that should access theoretically unlimited
(unstated)
number of connections.

Thanks for your feedback,
-- 
Adam
_______________________________________________
jabberd mailing list
jabberdjabberstudio.org
http:
//mail.jabber.org/mailman/listinfo/jabberd

ON ?RO, 2007-05-23 AT 19:17 +0200, ADAM STRZELECKI WROTE:
> STILL I'LL HAVE TO FIND A GOOD SOLUTION FOR DOING
"SELECT" ON WINDOWS
> WITHOUT WASTING ALL THOSE UNUSED RANGE OF DESCRIPTORS.


I WOULD RATHER GO FOR THE WINDOWS SPECIFIC MIO
IMPLEMENTATION.
THERE IS AN EPOLL/KQUEUE FUNCTIONAL EQUIVALENT ON WINDOWS
PLATFORM, TO
EFFICIENTLY HANDLE LARGE NUMBER OF CONNECTIONS THAT COULD BE
USED.


-- 
TOMASZ STERNA
XIAOKA GRP.  HTTP://WWW.XIAOKA.COM/

_______________________________________________
JABBERD MAILING LIST
JABBERDJABBERSTUDIO.ORG
HTTP://MAIL.JABBER.ORG/MAILMAN/LISTINFO/JABBERD