Imported from previous forum
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
Currently, FIX sessions generally are created as static connections to a given server, or maybe a primary / backup server pair.
I’d like to propose for inclusion in 4.2 fields that facilitate dynamic load balancing of FIX sessions across servers.
Such support would be entirely optional and would not affect connections not wishing to use this functionality.
The proposal is to add an optional repeating group to the Logon and Logout messages for use by the acceptor of a FIX session. This group would have the fields:
ConnectionPreferenceOrder (Int, ordered 1-N from most preferred to least preferred)
ConnectionHost (String)
ConnectionPort (String)
This allows a FIX server to inform the client the preference of all available FIX servers for that client’s connection. How preference order is calculated is left up to the acceptor of the connection; one possible metric would be the number of FIX clients currently connected to that server. Should the client experience a connection loss, the client knows which servers would be best to communicate with.
This also allows for a dynamic load splitter. A client could connect to a FIX server, which will always log the client out immediately, but in doing so, provides a list of preferred servers. This lets the client dynamically seek the least loaded server.
Bilateral agreement about use of these features must take place, and generally there would need to be limits placed on the address and port ranges which could be returned, since people usually have to configure their firewalls explicitly for FIX sessions.
This method might not work if NAT (Network Address Translation) is employed to translate the server addresses which the client sees, however the client addresses can be translated before sending them to the server.
This method is not IP-specific; host and port are generalized concepts which would naturally be an IP address or DNS name (again, bilateral agreement needed if DNS is used) for the host, and a number 1-65535 for the port. Other network protocols could use these two fields differently, which is why port is type String.
Thoughts?
The load balancing / high availability suggestion here is clearly simple to add and could be useful in contexts where any number of servers can serve the function and where there is a certain degree of statelessness. In light of this suggestion for "load" control, I was wondering why is there no message for "flow" control (Ala. XON/XOFF) which either end can send? Recently as part of 4.2, a new tag 369 has been introduced which can do this indirectly but only works when there is traffic in both directions simultaneously. Do you agree a throttling mechanism would be a useful addition in the context of ever higher bandwidth networks?
Avner Gelb
SIAC
> Currently, FIX sessions generally are created as static connections to a given server, or maybe a primary / backup server pair.
>
> I’d like to propose for inclusion in 4.2 fields that facilitate dynamic load balancing of FIX sessions across servers.
>
> Such support would be entirely optional and would not affect connections not wishing to use this functionality.
>
> The proposal is to add an optional repeating group to the Logon and Logout messages for use by the acceptor of a FIX session. This group would have the fields:
>
> ConnectionPreferenceOrder (Int, ordered 1-N from most preferred to least preferred)
> ConnectionHost (String)
> ConnectionPort (String)
>
> This allows a FIX server to inform the client the preference of all available FIX servers for that client’s connection. How preference order is calculated is left up to the acceptor of the connection; one possible metric would be the number of FIX clients currently connected to that server. Should the client experience a connection loss, the client knows which servers would be best to communicate with.
>
> This also allows for a dynamic load splitter. A client could connect to a FIX server, which will always log the client out immediately, but in doing so, provides a list of preferred servers. This lets the client dynamically seek the least loaded server.
>
> Bilateral agreement about use of these features must take place, and generally there would need to be limits placed on the address and port ranges which could be returned, since people usually have to configure their firewalls explicitly for FIX sessions.
>
> This method might not work if NAT (Network Address Translation) is employed to translate the server addresses which the client sees, however the client addresses can be translated before sending them to the server.
>
> This method is not IP-specific; host and port are generalized concepts which would naturally be an IP address or DNS name (again, bilateral agreement needed if DNS is used) for the host, and a number 1-65535 for the port. Other network protocols could use these two fields differently, which is why port is type String.
>
> Thoughts?
>
>
[ original email was from Danny Shobrook - dzshobrook@dial.pipex.com ]
Wouldn’t this be better off being done at a router level, ie programming the router to round robin a packet across a farm?
Also if you are running over IP - most are - or even X25, the transport will flow control for you.
> The load balancing / high availability suggestion here is clearly simple to add and could be useful in contexts where any number of servers can serve the function and where there is a certain degree of statelessness. In light of this suggestion for “load” control, I was wondering why is there no message for “flow” control (Ala. XON/XOFF) which either end can send? Recently as part of 4.2, a new tag 369 has been introduced which can do this indirectly but only works when there is traffic in both directions simultaneously. Do you agree a throttling mechanism would be a useful addition in the context of ever higher bandwidth networks?
>
> Avner Gelb
> SIAC
>
>
> > Currently, FIX sessions generally are created as static connections to a given server, or maybe a primary / backup server pair.
> >
> > I’d like to propose for inclusion in 4.2 fields that facilitate dynamic load balancing of FIX sessions across servers.
> >
> > Such support would be entirely optional and would not affect connections not wishing to use this functionality.
> >
> > The proposal is to add an optional repeating group to the Logon and Logout messages for use by the acceptor of a FIX session. This group would have the fields:
> >
> > ConnectionPreferenceOrder (Int, ordered 1-N from most preferred to least preferred)
> > ConnectionHost (String)
> > ConnectionPort (String)
> >
> > This allows a FIX server to inform the client the preference of all available FIX servers for that client’s connection. How preference order is calculated is left up to the acceptor of the connection; one possible metric would be the number of FIX clients currently connected to that server. Should the client experience a connection loss, the client knows which servers would be best to communicate with.
> >
> > This also allows for a dynamic load splitter. A client could connect to a FIX server, which will always log the client out immediately, but in doing so, provides a list of preferred servers. This lets the client dynamically seek the least loaded server.
> >
> > Bilateral agreement about use of these features must take place, and generally there would need to be limits placed on the address and port ranges which could be returned, since people usually have to configure their firewalls explicitly for FIX sessions.
> >
> > This method might not work if NAT (Network Address Translation) is employed to translate the server addresses which the client sees, however the client addresses can be translated before sending them to the server.
> >
> > This method is not IP-specific; host and port are generalized concepts which would naturally be an IP address or DNS name (again, bilateral agreement needed if DNS is used) for the host, and a number 1-65535 for the port. Other network protocols could use these two fields differently, which is why port is type String.
> >
> > Thoughts?
> >
> >
>
Upon further discussions with my peers, indeed a network based load balancer is the way to go.
Avner Gelb
SIAC
> Wouldn’t this be better off being done at a router level, ie programming the router to round robin a packet across a farm?
>
> Also if you are running over IP - most are - or even X25, the transport will flow control for you.
> > The load balancing / high availability suggestion here is clearly simple to add and could be useful in contexts where any number of servers can serve the function and where there is a certain degree of statelessness. In light of this suggestion for “load” control, I was wondering why is there no message for “flow” control (Ala. XON/XOFF) which either end can send? Recently as part of 4.2, a new tag 369 has been introduced which can do this indirectly but only works when there is traffic in both directions simultaneously. Do you agree a throttling mechanism would be a useful addition in the context of ever higher bandwidth networks?
> >
> > Avner Gelb
> > SIAC
> >
> >
> > > Currently, FIX sessions generally are created as static connections to a given server, or maybe a primary / backup server pair.
> > >
> > > I’d like to propose for inclusion in 4.2 fields that facilitate dynamic load balancing of FIX sessions across servers.
> > >
> > > Such support would be entirely optional and would not affect connections not wishing to use this functionality.
> > >
> > > The proposal is to add an optional repeating group to the Logon and Logout messages for use by the acceptor of a FIX session. This group would have the fields:
> > >
> > > ConnectionPreferenceOrder (Int, ordered 1-N from most preferred to least preferred)
> > > ConnectionHost (String)
> > > ConnectionPort (String)
> > >
> > > This allows a FIX server to inform the client the preference of all available FIX servers for that client’s connection. How preference order is calculated is left up to the acceptor of the connection; one possible metric would be the number of FIX clients currently connected to that server. Should the client experience a connection loss, the client knows which servers would be best to communicate with.
> > >
> > > This also allows for a dynamic load splitter. A client could connect to a FIX server, which will always log the client out immediately, but in doing so, provides a list of preferred servers. This lets the client dynamically seek the least loaded server.
> > >
> > > Bilateral agreement about use of these features must take place, and generally there would need to be limits placed on the address and port ranges which could be returned, since people usually have to configure their firewalls explicitly for FIX sessions.
> > >
> > > This method might not work if NAT (Network Address Translation) is employed to translate the server addresses which the client sees, however the client addresses can be translated before sending them to the server.
> > >
> > > This method is not IP-specific; host and port are generalized concepts which would naturally be an IP address or DNS name (again, bilateral agreement needed if DNS is used) for the host, and a number 1-65535 for the port. Other network protocols could use these two fields differently, which is why port is type String.
> > >
> > > Thoughts?
> > >
> > >
> >
>