u can take the idea with an example
say that u get with a "single framework" to interact with the outer world
what soever be the transport mechanism (weather it be a UDP or
TCP or Message Q's ) so, this transport is with a general library like
void* p_msg; /* Data */
Is_active id;/* will hold the id of the entity that is active at that moment */
enum transport_mechanism={ 'TCP' ,'UDP' , 'M_Q'};
/*Prototype of general library */
boolean send_to_world( p_msg,transport_mechanism, ,...);
boolean recv_from_world(p_msg, id, ...);
BEN> If you start modifying the stack, you will likely have to modify
BEN> everything above it (ie the VOIP program).
this way i think the VoIP program is not modified every time. Also to the outer
world
the entty which interact is a singleton , whereas inside the entity the
redundancy
of the VoIP box will only be cared ab't
sandeep kalra
Ben Greear <greearb@xxxxxxxxxxxxxxx> on 06/04/2001 12:38:41 PM
To: Sandeep Kalra/HSS@HSS
cc: netdev@xxxxxxxxxxx
Subject: Re: regarding Redundancy in TCP / IP Stack
sakalra@xxxxxxxxxxx wrote:
>
> hi,
>
> BEN> What redundancy do you expect to get? What will you
> BEN> be able to do that we cannot do today? You mean
> BEN> keeping two stacks in sync across two different machines, so
> BEN> that you can hot-swap processes or something?
>
> San> Yes, to be more precise, this will be a part of a big VoIP project
> San> and thats the world i belong to
> San> the idea of the project is to have a redundant VoIP entity (may be MG
> /Switch /or MGControllers)
> San> where there will be a Single floating IP, and the whole entity will be a
> single
> San> unit to the outside world. For UDP there is no problem implementing this
,
> but with TCP
> San> the stack has to be modified or what i think other ideas like
> San> a net-filter or going for hacking packets at the interface rather than
> San> allowing them to float to stack are also good.
If you start modifying the stack, you will likely have to modify
everything above it (ie the VOIP program). This will get nasty, because
the client on the other end of the TCP connection will have it's
own idea of sequence numbers, etc. As nasty as it sounds, I think
that just by-passing the tcp/ip stack alltogether may be the cleanest route.
This will mean re-implementing most of the stack in user space (ie your VOIP
program),
but maybe that is OK.
Depending on how forgiving TCP/IP is about sequence numbers (and it should
be able to handle duplicate and dropped ones, so it might just recover OK),
it may be possible to used a modified version of the existing TCP stack, but
you may spend 99% of your time chasing hard-to-catch border cases...
Have you considered just finding a piece of hardware/software combo that meets
5-9's, or whatever you are shooting for? Motorolla offers a 5-9's compact-PCI
shelf based on Linux, for example.
Also, since the RTP protocol is based off of UDP (which is admittedly easy to
fail-over), what is running over TCP that is so important?
--
Ben Greear <greearb@xxxxxxxxxxxxxxx> <Ben_Greear@xxxxxxxxxx>
President of Candela Technologies Inc http://www.candelatech.com
ScryMUD: http://scry.wanfear.com http://scry.wanfear.com/~greear
|