pidgin-devel

Hi. I know 30 million people have already asked about this,
and 5 million have said "I'm gonna write one." But, I'm start-
ing on writing one.
My company has moved to Microsoft OLCS, and is using a SIP
server. This should be *mostly* normal SIP I think, and/or
SIMPLE. So, I'm going to try to implement something open-source.
And, I don't have any access to MS code, so I'll just reverse
engineer anything I find near holes.
The first question I have, tho, is that our server does
SIP over UDP (as is common). The gaim core network code
seems to only understand TCP connections. They are
made in proxy.c, and are always SOCK_STREAM.
In talking to someone at #gaim today, they suggested
I augment gaim's core to allow UDP connection management
inside of gaim. While I could do this, I'd certainly want
to know of more people than myself interested in it. The
"right" way to do that would be to actually modify the
gaim_proxy_connect() (and friends) to take a "int type",
as well as the other side address/port information.
The other option would seem to be to have the prpl
actually do all of the connection handling. If I do this,
can I clue gaim in somehow to watch for that socket to
become readable, and when it is call me? It looks like
I can do this. I just want to make sure gaim doesn't
try to read the message off of the socket for me, since
it won't be a stream, it wouldn't make sure to get all
of the information, etc etc.
Any thoughts as to the best way to proceed with this?
The old IRQ code may have some clue how to do this, since
I think that was UDP code as well. But the only current thing
that seems to be a UDP-based protocol is Zephyr, and it's
all handled by the zephyr library.
Thanks. Let me know any thoughts you have. Keep me in
the dist list, because I'm not subscribed to gaim-devel.
- Chris

Chris Ross wrote:
>
> Hi. I know 30 million people have already asked about this,
> and 5 million have said "I'm gonna write one." But, I'm start-
> ing on writing one.
>
<snip>
Chris,
I'd encourage you to write this, however for the gaim-vv project
(gaim-vv.sf.net), as that's where the voice/video effort is.
At the moment, we don't have any working API for audio. But as we're
utilising Gstreamer, this shouldn't be too hard.
The bonus of writing for gaim-vv, is that we'll be able to re-use UI
parts across protocols on a consistent level.
The release of gaim-vv (1.2.0) is different from CVS. CVS removes the
insistence on 'webcam' and abstracts it out to 'media'. The API hasn't
been thoroughly adjusted yet, as we only have webcam receive operating
at the moment. The general idea will be that'media' encompasses
webacm/video(4l)/audio, etc.
If you decide to join the gaim-vv project, we'll be very excited to have
someone with some time to help out!
Regards,
Pete.

Chris Ross wrote:
> In talking to someone at #gaim today, they suggested
> I augment gaim's core to allow UDP connection management
> inside of gaim. While I could do this, I'd certainly want
> to know of more people than myself interested in it. The
> "right" way to do that would be to actually modify the
> gaim_proxy_connect() (and friends) to take a "int type",
> as well as the other side address/port information.
As far as I know, most proxies don't actually allow you to send UDP
packets - all of Gaim's proxy.c code is for setting up TCP streams that
go via other TCP streams. In the case of UDP packets, I'm not aware of a
proxy that forwards UDP packets for you, off-hand. So extending
gaim_proxy_connect seems a little pointless - the only reason TCP
connections are made through it is because it centralises the ability to
put them over proxies, which may not exist for UDP.
The API for TCP (open a socket, get a file descriptor, send with one
function, get a callback when data is received on it) is quite different
to that for UDP, and even if it proves necessary to abstract it via the
Gaim core for some hypothetical UDP proxy, should be done in an
appropriate way, distinct from the existing proxy stuff, not by hacking
it up.
> The other option would seem to be to have the prpl
> actually do all of the connection handling. If I do this,
> can I clue gaim in somehow to watch for that socket to
> become readable, and when it is call me? It looks like
> I can do this. I just want to make sure gaim doesn't
> try to read the message off of the socket for me, since
> it won't be a stream, it wouldn't make sure to get all
> of the information, etc etc.
Once you've got your file descriptor, use GLib's GIOChannel stuff and
you can get a function called (g_io_add_watch) when stuff arrives on
your socket, it gets closed, etc. This is the same mechanism that
gaim_proxy_* sets up to callback prpls when stuff happens on sockets.
> Thanks. Let me know any thoughts you have. Keep me in
> the dist list, because I'm not subscribed to gaim-devel.
Regards,
Rob
> - Chris

I should point out that gaim_proxy_connect is used for normal connections as
well as proxied connections. The function name is a holdover from the libfaim
version, as far as I know.
gaim_proxy_connect will connect to the given host on the given port using the
proxy setting specified in your preferences (this can be GAIM_PROXY_SOCKS5 or
GAIM_PROXY_NONE).
And Chris, it IS a good idea to deal with the voice/video parts of a
SIP/SIMPLE PRPL in gaim-vv instead of in gaim itself. But you can still write
a SIP/SIMPLE PRPL that does basic stuff and try to get that added to Gaim proper.
-Mark

On May 24, 2005, at 23:52, Mark Doliner wrote:
> I should point out that gaim_proxy_connect is used for normal
> connections as
> well as proxied connections. The function name is a holdover from the
> libfaim
> version, as far as I know.
>
> gaim_proxy_connect will connect to the given host on the given port
> using the
> proxy setting specified in your preferences (this can be
> GAIM_PROXY_SOCKS5 or
> GAIM_PROXY_NONE).
Right. I was able to figure that out by looking at it...
> And Chris, it IS a good idea to deal with the voice/video parts of a
> SIP/SIMPLE PRPL in gaim-vv instead of in gaim itself. But you can
> still write
> a SIP/SIMPLE PRPL that does basic stuff and try to get that added to
> Gaim proper.
I understand that. But, you must understand, SIP is simple the
protocol
I'm using. By first concern is actually just text chat. I agree that
if I get
to working on voice and/or video, it might be better to investigate
gaim-vv.
For now, tho, I want to stay in gaim, proper, since that's the only
features
I'm looking at supporting in the short term.
- Chris

Mark Doliner wrote:
> I should point out that gaim_proxy_connect is used for normal connections as
> well as proxied connections. The function name is a holdover from the libfaim
> version, as far as I know.
>
> gaim_proxy_connect will connect to the given host on the given port using the
> proxy setting specified in your preferences (this can be GAIM_PROXY_SOCKS5 or
> GAIM_PROXY_NONE).
I'm certainly aware of this - I said the connections go through it so
that the TCP stream can be set up over a proxy if necessary. However
there are no UDP proxies that I'm aware of, so unless someone turns up
and tells us about one, mutilating the TCP connection code to support
UDP connections is totally gratuitous. Not to mention trying to fit a
square peg in a round hole - even if a UDP proxy existed, it should be
added alongside the TCP code, not by trying to pretend UDP is stateful.
> And Chris, it IS a good idea to deal with the voice/video parts of a
> SIP/SIMPLE PRPL in gaim-vv instead of in gaim itself. But you can still write
> a SIP/SIMPLE PRPL that does basic stuff and try to get that added to Gaim proper.
>
> -Mark
Regards,
Rob

Robert McQueen wrote:
> Mark Doliner wrote:
>
>>I should point out that gaim_proxy_connect is used for normal connections as
>>well as proxied connections. The function name is a holdover from the libfaim
>>version, as far as I know.
>>
>>gaim_proxy_connect will connect to the given host on the given port using the
>>proxy setting specified in your preferences (this can be GAIM_PROXY_SOCKS5 or
>>GAIM_PROXY_NONE).
>
> I'm certainly aware of this - I said the connections go through it so
> that the TCP stream can be set up over a proxy if necessary. However
> there are no UDP proxies that I'm aware of, so unless someone turns up
> and tells us about one, mutilating the TCP connection code to support
> UDP connections is totally gratuitous. Not to mention trying to fit a
> square peg in a round hole - even if a UDP proxy existed, it should be
> added alongside the TCP code, not by trying to pretend UDP is stateful.
Right. I totally agree. While it would be possible to modify the
existing code to make a UDP "connection," it would be complicated. Trying
to get read(2)/write(2) to "do the right thing" given a non-stream
protocol would be a long drawn-out nightmare, I suspect. This isn't an
issue unless the connection/proxy code does reading and writing on it's
own, but I assume at least that it can.
I've started working on my own network code inside of the prpl.
I need to figure out how to hand things to back to the gaim core
event engine during connection, and after connection, so that I
get notified when things need to be done. But, I assume that will
all be doable once I figure it out. Sadly, the existing prpl's
shipped with gaim appear to be mostly TCP, and use the gaim_proxy_connect()
method, so I don't have any good examples to look at.
Does anyone have any suggestions or guidance on doing the connection
establishment myself, but still allowing gaim to process anything else
it needs to using the event engine? I'll just dig into the code and
see what I find. :-)
- Chris

Chris Ross wrote:
> Does anyone have any suggestions or guidance on doing the connection
> establishment myself, but still allowing gaim to process anything else
> it needs to using the event engine? I'll just dig into the code and
> see what I find. :-)
I already hinted at this - set up the connection as normal with socket()
and then add it to the sockets glib monitors with g_io_add_watch. Call a
"stuff received" function inside your prpl, and have a per-connection
structure as your user data. Gaim doesn't need to know anything about
your socket.
> - Chris
Regards,
Rob

Chris Ross spake unto us the following wisdom:
> Right. I totally agree. While it would be possible to modify the
> existing code to make a UDP "connection," it would be complicated. Trying
> to get read(2)/write(2) to "do the right thing" given a non-stream
> protocol would be a long drawn-out nightmare, I suspect. This isn't an
> issue unless the connection/proxy code does reading and writing on it's
> own, but I assume at least that it can.
I tried to explain this on IRC, and I think it's been hit up on this
list a couple of times. All you need to do is write a few functions
to _create_ the UDP connection, and then insert it into Gaim's
(glib's, by proxy) file event loop with appropriate functions for
processing the data. Gaim itself does not do _anything_ with file
descriptors that come available for read or write or what-have-you, it
simply calls a function which you define.
read() and write() trivially "do the right thing" on datagram sockets
in many instances. However, I suspect you're wanting to use a single
connectionless socket (which makes sense). In this case, all you do
is call recvfrom() (or whatever you intend to use) in the readable
handler for your socket, instead of read().
> I've started working on my own network code inside of the prpl.
> I need to figure out how to hand things to back to the gaim core
> event engine during connection, and after connection, so that I
> get notified when things need to be done. But, I assume that will
> all be doable once I figure it out. Sadly, the existing prpl's
> shipped with gaim appear to be mostly TCP, and use the gaim_proxy_connect=
()
> method, so I don't have any good examples to look at.
>=20
> Does anyone have any suggestions or guidance on doing the connection
> establishment myself, but still allowing gaim to process anything else
> it needs to using the event engine? I'll just dig into the code and
> see what I find. :-)
This is how all of the existing protocols work. Look at one of them.
Ethan
--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils]. They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, "On Crimes and Punishments", 1764

Robert McQueen wrote:
> I already hinted at this - set up the connection as normal with socket()
> and then add it to the sockets glib monitors with g_io_add_watch. Call a
> "stuff received" function inside your prpl, and have a per-connection
> structure as your user data. Gaim doesn't need to know anything about
> your socket.
Ahh, so it's glib thats doing that work, not gaim itself. (Well, not
gaim code, I mean) Okay, I didn't realize that. Thanks for the pointers,
and I'm sorry I didn't get the the first time you mentioned it. :-)
- Chris

Chris,
I definitely understand your concerns. It would be awesome to have some UDP=
=20
infrastructure in Gaim, as UPnP ( a new project that I'm trying to get=20
rolling ) also uses UDP for it's initial communications. I have been=20
successful with my UDP requests for UPnP services, but have not integrated=
=20
the code into Gaim-proper yet. I would also be interested in the submission=
=20
of non-standard HTTP requests, as UPnP requires SOAP specific headers to be=
=20
sent in the requests. This is more than just a simple HTTP-GET request. I=
=20
can help out to further our quests, especially if it meant getting our=20
projects accepted into the mainline code.
See http://www.geocities.com/moonunittt/code/upnp-test/upnp-test.c
or
http://www.geocities.com/moonunittt/code/upnp-test/upnp-test.tar.gz
for my UDP code.
Although it doesn't "look" like a connection to unix, it surely does act=20
like one when I use it, as I send the UDP request, and then wait for data t=
o=20
be received from the same protocol.
-Trevor
On 5/24/05, Chris Ross <cross+gaim@... > wrote:
>=20
>=20
> Hi. I know 30 million people have already asked about this,
> and 5 million have said "I'm gonna write one." But, I'm start-
> ing on writing one.
>=20
> My company has moved to Microsoft OLCS, and is using a SIP
> server. This should be *mostly* normal SIP I think, and/or=20
> SIMPLE. So, I'm going to try to implement something open-source.
> And, I don't have any access to MS code, so I'll just reverse
> engineer anything I find near holes.
>=20
> The first question I have, tho, is that our server does=20
> SIP over UDP (as is common). The gaim core network code
> seems to only understand TCP connections. They are
> made in proxy.c, and are always SOCK_STREAM.
>=20
> In talking to someone at #gaim today, they suggested=20
> I augment gaim's core to allow UDP connection management
> inside of gaim. While I could do this, I'd certainly want
> to know of more people than myself interested in it. The
> "right" way to do that would be to actually modify the=20
> gaim_proxy_connect() (and friends) to take a "int type",
> as well as the other side address/port information.
>=20
> The other option would seem to be to have the prpl
> actually do all of the connection handling. If I do this,=20
> can I clue gaim in somehow to watch for that socket to
> become readable, and when it is call me? It looks like
> I can do this. I just want to make sure gaim doesn't
> try to read the message off of the socket for me, since=20
> it won't be a stream, it wouldn't make sure to get all
> of the information, etc etc.
>=20
> Any thoughts as to the best way to proceed with this?
>=20
> The old IRQ code may have some clue how to do this, since=20
> I think that was UDP code as well. But the only current thing
> that seems to be a UDP-based protocol is Zephyr, and it's
> all handled by the zephyr library.
>=20
> Thanks. Let me know any thoughts you have. Keep me in=20
> the dist list, because I'm not subscribed to gaim-devel.
>=20
> - Chris
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net <http://SF.Net&gt; email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!=20
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22=
005
> _______________________________________________
> Gaim-devel mailing list
> Gaim-devel@...
> https://lists.sourceforge.net/lists/listinfo/gaim-devel
>

Trevor Carlson wrote:
> Chris,
>
> I definitely understand your concerns. It would be awesome to have
> some UDP infrastructure in Gaim, as UPnP ( a new project that I'm trying
> to get rolling ) also uses UDP for it's initial communications. I have
> been successful with my UDP requests for UPnP services, but have not
> integrated the code into Gaim-proper yet. I would also be interested in
> the submission of non-standard HTTP requests, as UPnP requires SOAP
> specific headers to be sent in the requests. This is more than just a
> simple HTTP-GET request. I can help out to further our quests,
> especially if it meant getting our projects accepted into the mainline code.
I would guess that adding some hooks into the HTTP code to do
extra things wouldn't be too hard. But, that's a separate issue
than the one that currently is facing me. Unless it got whacked
enough to be able to generate SIP, but that would be wrong anyway.
:-)
> Although it doesn't "look" like a connection to unix, it surely
> does act like one when I use it, as I send the UDP request, and then
> wait for data to be received from the same protocol.
Yeah, and I will be doing much the same thing, I think. What I
really need to figure out how to do at this point is to allow gaim's
event engine to handle all of that waiting for me, so that other
events can be dealt with normally. If my code does the waiting,
I'm sure it will screw things up for gaim.
Adding a UDP connection interface to gaim core might be a good
idea. But, I'm sure I don't know the gaim core design well enough
to want to take that on myself. I'd be happy to work on that project,
tho, if any of the primary developers think it would be a useful
addition, and can assist with pointers and guidance. Until then,
I will just keep working on writing that code into my prpl.
- Chris