Thread: Can a C function(server program) be a UDP or TCP server?

Hi there,<br /><br />Is it possible to write a dynamic loaded C function as an UDP or TCP server?<br /><br />What we
wantto do it is:<br />Add a search function which send a UDP package to remote UDP server<br />and then listen to an
UDPport, waiting for the result. <br />Ideally, we don't close the UDP server after the search query end.<br />So we
canreuse it for next search.<br /><br />Is it possible?<br /><br />Thanks<br /><br />Billow<br /> 

On Thu, 18 Oct 2007 10:55:19 -0400
"Billow Gao" <billowgy@gmail.com> wrote:
> Is it possible to write a dynamic loaded C function as an UDP or TCP server?
> 
> What we want to do it is:
> Add a search function which send a UDP package to remote UDP server
> and then listen to an UDP port, waiting for the result.
> Ideally, we don't close the UDP server after the search query end.
> So we can reuse it for next search.
> 
> Is it possible?

Short answer: yes.  Slightly longer answer: If you need to ask this
quetion then you should really talk to someone about network
programming but this is the wrong list.

If you are asking if PostgreSQL already does UDP then the answer is
no.  You need to write a server program that talks UDP in one direction
and TCP to PostgreSQL in the other direction.  Watch out for security
issues.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

On Thu, 18 Oct 2007 10:55:19 -0400<br />"Billow Gao" <<a href="mailto:billowgy@gmail.com">billowgy@gmail.com</a>>
wrote:<br/>> Is it possible to write a dynamic loaded C function as an UDP or TCP server? <br />><br />> What
wewant to do it is:<br />> Add a search function which send a UDP package to remote UDP server<br />> and then
listento an UDP port, waiting for the result.<br />> Ideally, we don't close the UDP server after the search query
end.<br />> So we can reuse it for next search.<br />><br />> Is it possible?<br /><br />>Short answer:
yes. Slightly longer answer: If you need to ask this<br />>quetion then you should really talk to someone about
network<br />>programming but this is the wrong list.<br /><br />Thanks for your reply.<br /><br />I can write the
networkprogram.<br />But I am not 100% sure whether I can add the c-language function (<a
href="http://www.postgresql.org/docs/8.2/interactive/xfunc-c.html">
http://www.postgresql.org/docs/8.2/interactive/xfunc-c.html</a>)<br/>to PostgreSQL. The function will be dynamic loaded
byPostgreSQL. <br />I want to know whether there are any limitation on the function I wrote.<br /><br />for example:
<br/>If I want to write a function: <br /><pre class="PROGRAMLISTING">PG_FUNCTION_INFO_V1(c_talktoremoteudp);</pre><br
/>Anduse it in PostgreSQL like:<br /><br />=========================================<br />SELECT name,
c_talktoremoteudp<br /><pre class="PROGRAMLISTING">(emp, 1500) AS overpaid<br />    FROM emp<br />    WHERE name =
'Bill'OR name = 'Sam';</pre>=========================================<br />The function c_talktoremoteudp will:<br />
1.send udp data to remote udp server<br />2. monitor an udp port and wait for the reply<br />3. return the data to the
selectquery.<br /><br />Anyway, I guess that it can be done. I will write a simple function to test it.<br /><br />
Ying<br/><br /><br />>If you are asking if PostgreSQL already does UDP then the answer is<br />>no.  You need to
writea server program that talks UDP in one direction<br />>and TCP to PostgreSQL in the other direction.  Watch out
forsecurity <br />>issues.  

On Thu, 18 Oct 2007 11:24:24 -0400
"Billow Gao" <billowgy@gmail.com> wrote:
> I can write the network program.
> But I am not 100% sure whether I can add the c-language function (
> http://www.postgresql.org/docs/8.2/interactive/xfunc-c.html)
> to PostgreSQL. The function will be dynamic loaded by PostgreSQL.
> I want to know whether there are any limitation on the function I wrote.
> 
> for example:
> If I want to write a function:
> 
> PG_FUNCTION_INFO_V1(c_talktoremoteudp);
> 
> 
> And use it in PostgreSQL like:
> 
> =========================================
> SELECT name, c_talktoremoteudp
> 
> (emp, 1500) AS overpaid
>     FROM emp
>     WHERE name = 'Bill' OR name = 'Sam';
> 
> =========================================
> The function c_talktoremoteudp will:
> 1. send udp data to remote udp server
> 2. monitor an udp port and wait for the reply
> 3. return the data to the select query.

I am confused.  The dynamic function resides in the server.  The query
runs in the server.  Where is the "remoteness" in any of this?  Are you
saying that there is a second server that is not PostgreSQL that uses
UDP that you want to communicate with and merge info into the
PostgreSQL server from?

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

"D'Arcy J.M. Cain" <darcy@druid.net> writes:

> On Thu, 18 Oct 2007 11:24:24 -0400
>> And use it in PostgreSQL like:
>> 
>> =========================================
>> SELECT name, c_talktoremoteudp(emp, 1500) AS overpaid
>>     FROM emp
>>     WHERE name = 'Bill' OR name = 'Sam';
>> 
>> =========================================
>> The function c_talktoremoteudp will:
>> 1. send udp data to remote udp server
>> 2. monitor an udp port and wait for the reply
>> 3. return the data to the select query.
>
> I am confused.  The dynamic function resides in the server.  The query
> runs in the server.  Where is the "remoteness" in any of this?  Are you
> saying that there is a second server that is not PostgreSQL that uses
> UDP that you want to communicate with and merge info into the
> PostgreSQL server from?

Yeah, what he wants is to implement a function in Postgres which does
something like an LDAP or DNS lookup or something like that.

Sure you can do this. The only tricky bit is the thing you mentioned about
reusing the connection. You could always leave the connection in a safe state
and don't need to worry about cleaning it up then you could just store it in a
static variable which would be the simplest option.

If you want to use Postgres's facilities for allocating memory and cleaning it
up when no longer in use you can use some of the Postgres internal API for
memory contexts and resource owners. But I don't see any particular reason you
should need to worry about this stuff for something simple you're implementing
yourself.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com

On Thursday 18 October 2007 12:27:59 Billow Gao wrote:
> Thanks.  This is what I want to know :-)
>
> Regards,
>
> Billow
>
> >Yeah, what he wants is to implement a function in Postgres which does
> >something like an LDAP or DNS lookup or something like that.
> >
> >Sure you can do this. The only tricky bit is the thing you mentioned about
> >reusing the connection. You could always leave the connection in a safe
> > state and don't need to worry about cleaning it up then you could just
> > store it in a static variable which would be the simplest option.
> >
> >If you want to use Postgres's facilities for allocating memory and
> > cleaning it up when no longer in use you can use some of the Postgres
> > internal API for memory contexts and resource owners. But I don't see any
> > particular reason you should need to worry about this stuff for something
> > simple you're implementing yourself.

> On 10/18/07, D'Arcy J.M. Cain <darcy@druid.net> wrote:
>  On Thu, 18 Oct 2007 11:24:24 -0400
>
> "Billow Gao" <billowgy@gmail.com> wrote:
> > I can write the network program.
> > ...

Oh my. The worst kind of top-poster: the kind that copies *your* reply from
the bottom to the top and top-posts above that.

Shudder...

:)

jan

--
--------------------------------------------------------------
Jan de Visser                     jdevisser@digitalfairway.com

                Baruk Khazad! Khazad ai-menu!
--------------------------------------------------------------