Persistent communication session inside sqlclr proc?

I suspect this is very poor design but I've been asked to research this: can I maintain a persistent communication session inside an sqlclr proc? (tcp/binary packets)

The process has to maintain very high throughput - setting up and tearing down a connection on each transaction is cost prohibitive. For TCO and deployment reasons it is preferable not to have a separate windows service etc that accepts requests from inside the clr proc. Is there the luxury of an alternative integrated into the database?

DONT DO THIS, stored procedures are not windows services. And i believe SQL Server monitors for long running CLR threads and will auto-suspend them. There is some bits and pieces about this in BOL2005.|||Thanks Derek - I have all the ammunition I need know to make an alternate design proposal. I think we've all seen in the past what happens when database servers are used for anything else than a persistence sink and transaction/report processor. Hardware is just too cheap to misuse platforms like this.|||

if you are satisfied please mark an answer.

Thanks,

"D"

sql