I am planning to build a Messaging Systems using messaging protocol
SMTP,MIME,POP and IMAP for a Stock Exchange to work as
a Financial Hub Powered by UNIX (FreeBSD/Linux) in order
to exchange notes and orders between the brokers.

Any advice would be really appreciated?

Thanks

[ Post a follow-up to this message ]

On Thu, 17 Jul 2003 09:01:36 +0200, "Jaz" <jazxyz@web.de> wrote:
quote:

>I am planning to build a Messaging Systems using messaging protocol
>SMTP,MIME,POP and IMAP for a Stock Exchange to work as
>a Financial Hub Powered by UNIX (FreeBSD/Linux) in order
>to exchange notes and orders between the brokers.
>
>Any advice would be really appreciated?
>
>Thanks
>
>

To keep out of hot water, your solution is going to have to be able to
retain all electronic messages (e-mail, logging, IM, etc) for a
significant amount of time.  Better check the SEC rules about this
since it's your employer who will get nailed if this isn't done
properly.

Think about how much it will cost the business by using consumer grade
equipment in this type of high-speed-low-drag environment, and how
expensive it'll be when it fails.  The design has to be able to
provide a HA, cluster, or equivalent type solution that provides
better than 5 9s uptime.

There are plenty of other things, but that gets into the billable
hours section of my time.  :-)

[ Post a follow-up to this message ]

On Thu, 17 Jul 2003 09:01:36 +0200, "Jaz" <jazxyz@web.de> wrote:
quote:

>I am planning to build a Messaging Systems using messaging protocol
>SMTP,MIME,POP and IMAP for a Stock Exchange to work as
>a Financial Hub Powered by UNIX (FreeBSD/Linux) in order
>to exchange notes and orders between the brokers.
>
>Any advice would be really appreciated?
>
>Thanks
>
>

To keep out of hot water, your solution is going to have to be able to
retain all electronic messages (e-mail, logging, IM, etc) for a
significant amount of time.  Better check the SEC rules about this
since it's your employer who will get nailed if this isn't done
properly.

Think about how much it will cost the business by using consumer grade
equipment in this type of high-speed-low-drag environment, and how
expensive it'll be when it fails.  The design has to be able to
provide a HA, cluster, or equivalent type solution that provides
better than 5 9s uptime.

There are plenty of other things, but that gets into the billable
hours section of my time.  :-)

[ Post a follow-up to this message ]

"Jaz" <jazxyz@web.de> writes:
quote:

> I am planning to build a Messaging Systems using messaging protocol
> SMTP,MIME,POP and IMAP for a Stock Exchange to work as
> a Financial Hub Powered by UNIX (FreeBSD/Linux) in order
> to exchange notes and orders between the brokers.
> Any advice would be really appreciated?


Sounds like you'll want a high-performance, high-availability mail server.
Research the following:
* clustering
* high availability
* backups
* UPS
* RAID

Without knowing your specific setup, it's impossible to give any
specific advice.

--
****** Juhana Siren ***** Juhana.Siren@oulu.fi ***** OH8HTH (2 m, 70 cm) ***
***
On pienempi paha nolata itsensä tyhmällä kysymyksellä kuin rikkomalla jotaki
n.
--minä--

[ Post a follow-up to this message ]

"Jaz" <jazxyz@web.de> writes:
quote:

> I am planning to build a Messaging Systems using messaging protocol
> SMTP,MIME,POP and IMAP for a Stock Exchange to work as
> a Financial Hub Powered by UNIX (FreeBSD/Linux) in order
> to exchange notes and orders between the brokers.
> Any advice would be really appreciated?


Sounds like you'll want a high-performance, high-availability mail server.
Research the following:
* clustering
* high availability
* backups
* UPS
* RAID

Without knowing your specific setup, it's impossible to give any
specific advice.

--
****** Juhana Siren ***** Juhana.Siren@oulu.fi ***** OH8HTH (2 m, 70 cm) ***
***
On pienempi paha nolata itsensä tyhmällä kysymyksellä kuin rikkomalla jotaki
n.
--minä--

[ Post a follow-up to this message ]

Juhana Siren <Juhana.Siren@oulu.fi> writes:
quote:

> "Jaz" <jazxyz@web.de> writes: 
> Sounds like you'll want a high-performance, high-availability mail server.


Following up to myself:

Also consider whether FreeBSD and Linux, presumably on PC hardware,
are the best choices for the job at hand, or if it might be better
done with another hardware architecture and associated OS. The answer
depends on your situation. I've seen both kinds of cases. The point is
to think about it.

Analyze your needs very carefully; find out what's required by law,
company procedure, users' needs, your needs... Things that might be
affected are, for example, security, privacy, storage times,
permissible delays... You'll probably think of more. Think of what's
reasonable and what's feasible.

--
****** Juhana Siren ***** Juhana.Siren@oulu.fi ***** OH8HTH (2 m, 70 cm) ***
***
On pienempi paha nolata itsensä tyhmällä kysymyksellä kuin rikkomalla jotaki
n.
--minä--

[ Post a follow-up to this message ]

Juhana Siren <Juhana.Siren@oulu.fi> writes:
quote:

> "Jaz" <jazxyz@web.de> writes: 
> Sounds like you'll want a high-performance, high-availability mail server.


Following up to myself:

Also consider whether FreeBSD and Linux, presumably on PC hardware,
are the best choices for the job at hand, or if it might be better
done with another hardware architecture and associated OS. The answer
depends on your situation. I've seen both kinds of cases. The point is
to think about it.

Analyze your needs very carefully; find out what's required by law,
company procedure, users' needs, your needs... Things that might be
affected are, for example, security, privacy, storage times,
permissible delays... You'll probably think of more. Think of what's
reasonable and what's feasible.

--
****** Juhana Siren ***** Juhana.Siren@oulu.fi ***** OH8HTH (2 m, 70 cm) ***
***
On pienempi paha nolata itsensä tyhmällä kysymyksellä kuin rikkomalla jotaki
n.
--minä--

[ Post a follow-up to this message ]

On Thu, 17 Jul 2003 14:45:12 +0000 (UTC), Jeremiah DeWitt Weiner
<jdw@panix.com> wrote:
quote:

>Mountain Man <KeepYouSpamToYourself@leavemealone.com> wrote: 
>
>	A lot of financial firms also can't afford to have downtime
>for backups, so that needs to be considered too, which may mean stuff
>like three-way mirrors so you can split one off and back it up, or
>real-time data duplication to an offsite location.  Then again, I
>think brokers are supposed to be a little easier in this respect,
>since trading does end at a certain time.
>


The exact details of the backup requirements will obviously vary
depending on the OP's situation, but some highly reliable backup
system is pretty likely to be a requirement.   (The OP has a German
E-mail address, I see.  However, in the US, for example, you must
record all E-mail, IM, voice, etc.)

The OP mentioned orders in his question.  If this means trading orders
from customers, then you need to be VERY careful; I personally would
not opt for E-mail technology for this, because:
--These absolutely must be archived (to protect all parties).
--They must be delivered strictly in the order received.
--They must have accurate time stamps, authentication, etc.
--The delivery system must be reliable, and timely.

Basically,  you are likely to be operating in an environment where
anything more than a trivial systems failure is likely to be a hanging
offence.
quote:

>	But yes, do centralize, do cluster, and do use hot-swappable
>components as much as possible.  Brokers are not known for their laid-
>back attitudes and tolerance of interruptions in their work!  I'd
>recommend using some kind of terminal (X, VNC, SunRay, whatever) rather
>than a regular PC, so that if one breaks, you can just throw it off the
>trader's desk, throw on a new one, and go, with no loss of data and no
>reconfiguration to do.


Yes, that is a good point.  In the last large trading system (about
250 seats) I had a part in designing, we used low-end Unix
workstations rather than, say X-terms, but they were all run dataless
and identically configured, with only the OS and X on the local hard
disk -- and we always had a few spares already built on hand.

Everything else (apps, market data, transaction and position dB, etc.)
was on servers, each of which had at least one hot-standby machine.

Also remember the other aspects of reliability: available support
staff, uninterruptible power, ...

If you try to cut corners to save money or time, you had  better be
VERY SURE that everyone up to and including the CEO understands the
risks and has signed off on it -- in writing.   (And don't lose that
paper, and keep your bank account topped up. ;-)
--
Rich Gibbs
rgibbs@his.com

[ Post a follow-up to this message ]

On Thu, 17 Jul 2003 14:45:12 +0000 (UTC), Jeremiah DeWitt Weiner
<jdw@panix.com> wrote:
quote:

>Mountain Man <KeepYouSpamToYourself@leavemealone.com> wrote: 
>
>	A lot of financial firms also can't afford to have downtime
>for backups, so that needs to be considered too, which may mean stuff
>like three-way mirrors so you can split one off and back it up, or
>real-time data duplication to an offsite location.  Then again, I
>think brokers are supposed to be a little easier in this respect,
>since trading does end at a certain time.
>


The exact details of the backup requirements will obviously vary
depending on the OP's situation, but some highly reliable backup
system is pretty likely to be a requirement.   (The OP has a German
E-mail address, I see.  However, in the US, for example, you must
record all E-mail, IM, voice, etc.)

The OP mentioned orders in his question.  If this means trading orders
from customers, then you need to be VERY careful; I personally would
not opt for E-mail technology for this, because:
--These absolutely must be archived (to protect all parties).
--They must be delivered strictly in the order received.
--They must have accurate time stamps, authentication, etc.
--The delivery system must be reliable, and timely.

Basically,  you are likely to be operating in an environment where
anything more than a trivial systems failure is likely to be a hanging
offence.
quote:

>	But yes, do centralize, do cluster, and do use hot-swappable
>components as much as possible.  Brokers are not known for their laid-
>back attitudes and tolerance of interruptions in their work!  I'd
>recommend using some kind of terminal (X, VNC, SunRay, whatever) rather
>than a regular PC, so that if one breaks, you can just throw it off the
>trader's desk, throw on a new one, and go, with no loss of data and no
>reconfiguration to do.


Yes, that is a good point.  In the last large trading system (about
250 seats) I had a part in designing, we used low-end Unix
workstations rather than, say X-terms, but they were all run dataless
and identically configured, with only the OS and X on the local hard
disk -- and we always had a few spares already built on hand.

Everything else (apps, market data, transaction and position dB, etc.)
was on servers, each of which had at least one hot-standby machine.

Also remember the other aspects of reliability: available support
staff, uninterruptible power, ...

If you try to cut corners to save money or time, you had  better be
VERY SURE that everyone up to and including the CEO understands the
risks and has signed off on it -- in writing.   (And don't lose that
paper, and keep your bank account topped up. ;-)
--
Rich Gibbs
rgibbs@his.com

[ Post a follow-up to this message ]

I need to prepare a study (white paper) how to build a trader system and
the initialized cost of it.
Any help in this issue.

Thanks

"Juhana Siren" <Juhana.Siren@oulu.fi> wrote in message
news:m37k6he9y0.fsf@oulu.fi...
quote:

> Juhana Siren <Juhana.Siren@oulu.fi> writes:
> 
server.[QUOTE]
>
> Following up to myself:
>
> Also consider whether FreeBSD and Linux, presumably on PC hardware,
> are the best choices for the job at hand, or if it might be better
> done with another hardware architecture and associated OS. The answer
> depends on your situation. I've seen both kinds of cases. The point is
> to think about it.
>
> Analyze your needs very carefully; find out what's required by law,
> company procedure, users' needs, your needs... Things that might be
> affected are, for example, security, privacy, storage times,
> permissible delays... You'll probably think of more. Think of what's
> reasonable and what's feasible.
>
> --
> ****** Juhana Siren ***** Juhana.Siren@oulu.fi ***** OH8HTH (2 m, 70 cm)

******
quote:

> On pienempi paha nolata itsensä tyhmällä kysymyksellä kuin rikkomalla

jotakin.
quote:

>  --minä--

[ Post a follow-up to this message ]