Menu
▾
▴
icqlib-dev
You can subscribe to this list here.
| 2000 |
Jan
(16) |
Feb
(6) |
Mar
(1) |
Apr
(5) |
May
(8) |
Jun
(12) |
Jul
(19) |
Aug
(4) |
Sep
(2) |
Oct
(5) |
Nov
(2) |
Dec
(13) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(22) |
Feb
(12) |
Mar
(23) |
Apr
(3) |
May
(10) |
Jun
(26) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Denis V. D. <de...@nu...> - 2001-06-05 02:35:03
|
2001-06-04 Denis V. Dmitrienko <de...@kd...> * icqlib/udphandle.c: Make sure to send Acknowledgement packet before callback. * icqlib/udp.c: Added use of ICQ_MAX_UDP_MESSAGE_SIZE constant. * icqlib/icqpacket.c, icqlib/icqpacket.h, icqlib/udphandle.c: Added handling for V3 Wrong Password packet. * icqlib/proxy.c: "Do it right" fix for the previous one. ;) * icqlib/icqtypes.h: More Win32 compatibility fixes. 2001-06-04 Bill Soudan <so...@kd...> Applied patch via email from Richard Hughes <ri...@rh...>. Applied sf patches #429108 and #429111 from Michael M=F6ller <mc...@us...>. * icqlib/filesession.c: win32 compatability fixes, bugfixes. * icqlib/icq.h.in: add ICQ_MAX_* constants, away message request and callback. * icqlib/icqlib.c: fix crash in icq_LinkDestroy when tcp was disabled, cleanups. * icqlib/proxy.c: don't crash if NULL is passed in for pname and ppass to icq_SetProxy * icqlib/socketmanager.h, icqlib/tcplink.c: win32 compatability fixes. * icqlib/stdpackets.c, icqlib/stdpackets.h: added = icq_TCPCreateAwayReqPacket * icqlib/tcp.c: use ICQ_MAX_MESSAGE_SIZE constant, win32 fixes, copy files array in icq_SendFileRequest, bugfix for file xfer. * icqlib/tcpchathandle.c, icqlib/tcpfilehandle.c: factoring * icqlib/tcphandle.c: away message request support -- = Denis V. Dmitrienko | E-mail: de...@de... | ICQ#: 5538614 Home page: http://denix.org | de...@kd... History became legend... Legend became myth. And some things that should not have been forgotten ...were lost. |
|
From: Eric W. <war...@ya...> - 2001-06-01 23:54:24
|
Hi, Some systems don't have socklen_t typedef'd, and so fail when compiling and socketmanager.c and files that include socketmanager.h (looks like just icqlib.c). Looks like this got changed to int in tcplink.c a while back; on my system it's typedef'd as unsigned int though. Eric |
|
From: Michael M. <mic...@in...> - 2001-05-31 19:37:33
|
Hi everybody,
I submitted a patch for icqlib that allows filetransfer in kicq. Perhaps
someone will have a look at it (I'm not sure if it is a sufficient
solution, especially may way of copying the file names.) I provided the
patch on the sourceforge page.
bye,
Michael
--
Michael Moeller Universitaet Oldenburg, Fachbereich Informatik,
Postfach 25 03, 26111 Oldenburg
Tel.:0441 798-3483 Raum: A3 2-218
mailto:Mic...@in...
|
|
From: Michael M. <mic...@in...> - 2001-05-31 19:30:01
|
On Thursday, 31. May 2001 02:15, Denis V. Dmitrienko wrote: [...] > > > Also, I had a question about the InvalidUIN and WrongPassword > > callbacks. In udphandle.c, the both have invoke_callback followed by > > > > icq_UDPAck(icqlink, seq); > > > > In kicq though, both callbacks lead to the icqlink being deleted > > (both callbacks call RegWindow::stop, which calls > > RegWindow::disconnect, which calls icq_ICQLINKDelete). > > > > Once the icqlink is deleted, it returns to icq_ServerResponse in > > udphandle.c, which immediately tries to use it. > > > > Shouldn't the calls be reversed? The icq_UDPAck first and then > > invoke_callback? > > Hmm, it is more than just 2 callbacks. Most of the time we send > acknowledgement packet after calling callback. Which I think could cause > problems if client try to disconnect/delete icq_Link inside the > callback, and which is causing them in kicq's RegWindow right now. > Probably calling callbacks after acknowledging the packet would solve > this kind of problems in general and RegWindow crash in particular. I agree with you, that acknowledging the packet before calling callbacks should be more save. But I encountered another problem with the same result (RegWindow crash): When registering a new UIN with correct password the icqlib tried to delete some tcp stuff, although it was not in use and therefore not allocated. In my situation testing for icq_UseTCP before calling icq_TCPDone helped. Perhaps this will fix Eric Warmenhoven's problem as well. I submitted a patch on http://sourceforge.net/projects/icqlib -- Michael Moeller Universitaet Oldenburg, Fachbereich Informatik, Postfach 25 03, 26111 Oldenburg Tel.:0441 798-3483 Raum: A3 2-218 mailto:Mic...@in... |
|
From: Denis V. D. <de...@nu...> - 2001-05-31 00:13:03
|
Eric Warmenhoven <war...@ya...> writes: > Hi, > > In order to compile the icqlib that's currently in CVS on FreeBSD 4.2, I > had to add > > #include <sys/types.h> > > before the sys/socket.h include in icqpacket.c and socketmanager.h. Thanks for this, fixed. > Also, I had a question about the InvalidUIN and WrongPassword callbacks. > In udphandle.c, the both have invoke_callback followed by > > icq_UDPAck(icqlink, seq); > > In kicq though, both callbacks lead to the icqlink being deleted > (both callbacks call RegWindow::stop, which calls RegWindow::disconnect, > which calls icq_ICQLINKDelete). > > Once the icqlink is deleted, it returns to icq_ServerResponse in udphandle.c, > which immediately tries to use it. > > Shouldn't the calls be reversed? The icq_UDPAck first and then > invoke_callback? Hmm, it is more than just 2 callbacks. Most of the time we send acknowledgement packet after calling callback. Which I think could cause problems if client try to disconnect/delete icq_Link inside the callback, and which is causing them in kicq's RegWindow right now. Probably calling callbacks after acknowledging the packet would solve this kind of problems in general and RegWindow crash in particular. -- Denis V. Dmitrienko | E-mail: de...@de... | ICQ#: 5538614 Home page: http://denix.org | de...@kd... History became legend... Legend became myth. And some things that should not have been forgotten ...were lost. |
|
From: Eric W. <war...@ya...> - 2001-05-30 23:37:40
|
Hi, In order to compile the icqlib that's currently in CVS on FreeBSD 4.2, I had to add #include <sys/types.h> before the sys/socket.h include in icqpacket.c and socketmanager.h. Also, I had a question about the InvalidUIN and WrongPassword callbacks. In udphandle.c, the both have invoke_callback followed by icq_UDPAck(icqlink, seq); In kicq though, both callbacks lead to the icqlink being deleted (both callbacks call RegWindow::stop, which calls RegWindow::disconnect, which calls icq_ICQLINKDelete). Once the icqlink is deleted, it returns to icq_ServerResponse in udphandle.c, which immediately tries to use it. Shouldn't the calls be reversed? The icq_UDPAck first and then invoke_callback? Eric |
|
From: Bill S. <we...@ri...> - 2001-05-29 04:54:40
|
Hi all,
Here's the initial outline for the icqlib documentation that I'd like to
write over the summer.
Any suggestions/additions? This is meant to be more like a tutorial, not
a reference guide that covers ALL icqlib features, though I'd like to
touch on all the major ones.
Bill
----
1. introduction
* features
* supported platforms
* version history
2. installation
* download locations
* source
* cvs
* rpm
* bindings
3. icq protocol concepts
* terminology
* version history
* server/UDP protocol
* peer-to-peer/TCP protocol
4. icqlib design and concepts
* icq_Link
* asynchronous calls
* callbacks
1. icq_RequestNotify/icq_FileNotify/icq_ChatNotify
* icqlib mainloop
4. getting started
* library location, header name
* compiler flags, gcc
1. static linking
2. shared linking
* icqlib mainloop support
1. how to make your decision
2. polling - icq_Main
3. event driven - timeout manager, socket manager
* icqlib/icq_Link initialization
1. socks proxy
5. lifetime of an icq session
* login requirements/sequence
1. icq_Connect
2. icq_Login
* icq_WrongPassword
* icq_InvalidUIN
* icq_Logged
3. icq_SendContactList
* icq_Contact*
* maintaining connection
1. icq_KeepAlive
2. icq_Disconnected
* logout procedure
1. icq_Logout
6. basic messaging
* outgoing
1. icq_SendMessage
2. icq_SendURL
3. others
* icq_RequestNotify
* incoming
1. icq_RecvMessage
2. icq_RecvURL
3. others
7. user information/configuration
* visibile/invisible lists
* user info/meta info
* contact searches
8. advanced messaging
* chat and file requests introduction
* chat sessions
* file sessions
9. new user registration
* ???
10. icqlib projects
11. references
|
|
From: Bill S. <we...@ri...> - 2001-05-29 04:12:19
|
2001-05-28 Bill Soudan <so...@kd...>
* icqlib/contacts.c, icqlib/list.h, icqlib/queue.c,
icqlib/socketmanager.c, icqlib/tcplink.c, icqlib/util.c:
fix typo, icq_LinkEnqueue->icq_ListEnqueue, icq_LinkDequeue->
icq_ListDequeue
* icqlib/timeout.c: fix icq_Link->icq_List typo, fix memory
leak in icq_HandleTimeout
* icqlib/list.c: don't delete list items if NULL is passed into
icq_ListDelete for item_free_f
|
|
From: Denis V. D. <de...@nu...> - 2001-05-24 02:02:16
|
2001-05-24 Denis V. Dmitrienko <de...@kd...> * icqlib/udp.c: Fixed memory leak - acknowledgement packet never been freed!!! -- Denis V. Dmitrienko | E-mail: de...@de... | ICQ#: 5538614 Home page: http://denix.org | de...@kd... History became legend... Legend became myth. And some things that should not have been forgotten ...were lost. |
|
From: Denis V. D. <de...@nu...> - 2001-05-23 01:33:38
|
2001-05-23 Denis V. Dmitrienko <de...@kd...> * icqlib/icqlib.c, icqlib/udphandle.c: UDP implementation of the Receive Contact List feature. * icqlib/icqbyteorder.c, icqlib/icqbyteorder.h, configure.in: Portability changes. * icqlib/icqlib.h, CHANGES_SINCE_1.0: Cleanup. * icqlib/cyrillic.c: Applied koi8-u related patch by Kunytsa Olexander <xa...@sn...> -- Denis V. Dmitrienko | E-mail: de...@de... | ICQ#: 5538614 Home page: http://denix.org | de...@kd... History became legend... Legend became myth. And some things that should not have been forgotten ...were lost. |
|
From: Bill S. <we...@ri...> - 2001-05-09 01:20:58
|
On Tue, 8 May 2001, Denis V. Dmitrienko wrote: > "Henric Larsson" <h-...@ak...> writes: > > > Hi, I'm trying to do some work on the miranda codebase. but I can't figure > > out how to do automatic resend of packages that doesn't get ACK'ed by the > > server. > > You should use icq_SetTimeout callback which tells you to wait "interval" > seconds and call icq_HandleTimeout() function back when that timeout has > elapsed. > > It is correct for icqlib 1.0.0. I'm not sure about latest icqlib > though. Bill added some more features to the "Timeout Manager" code. > It should work the same way but there could be some tweaks. You're right, to the library client it works exactly the same way. I just generalized the code so I could use them in my TCP code, and made some improvements... Mainly the timeout manager keeps a sorted list of all the timeouts so it doesn't need to send out an icq_SetTimeout call for every timer. The library client only needs to manage one timer at a time now, which should be easier for the library users. Old code that manages multiple timers will still work, it's just not necessary to handle more than one timer anymore. It doesn't hurt to call icq_HandleTimeout multiple times, it will just do nothing if there are no expired timeouts. New method looks something like this: .. 2 udp packets go out, 10 second timeout for each ... icq_SetTimeout(10); /* app should call icq_HandleTimeout in 10 seconds */ .. 5 seconds elapse .. .. 1 udp packet goes out, 10 second timeout, note no set timeout call! .. .. 5 seconds elapse .. icq_HandleTimeout(); /* app calls handle timeout */ .. icqlib processes first 2 UDP timeouts during handle timeout call .. .. after processing timeouts, next timeout is expired in 5 seconds .. icq_SetTimeout(5); /* app should call icq_HandleTimeout in 5 seconds */ .. 5 seconds elapse .. icq_HandleTimeout(); /* app calls handle timeout */ Bill |
|
From: Denis V. D. <de...@nu...> - 2001-05-08 23:51:19
|
"Henric Larsson" <h-...@ak...> writes: > Hi, I'm trying to do some work on the miranda codebase. but I can't figure > out how to do automatic resend of packages that doesn't get ACK'ed by the > server. You should use icq_SetTimeout callback which tells you to wait "interval" seconds and call icq_HandleTimeout() function back when that timeout has elapsed. It is correct for icqlib 1.0.0. I'm not sure about latest icqlib though. Bill added some more features to the "Timeout Manager" code. It should work the same way but there could be some tweaks. -- Denis V. Dmitrienko | E-mail: de...@de... | ICQ#: 5538614 Home page: http://denix.org | de...@kd... History became legend... Legend became myth. And some things that should not have been forgotten ...were lost. |
|
From: Bill S. <we...@ri...> - 2001-04-16 03:01:54
|
Interesting idea, a service that tracks when your friends log off and on icq. Based on icqlib. http://www.icqtrack.com/acknowledgements.php Bill |
|
From: Bill S. <we...@ri...> - 2001-04-05 00:55:11
|
2001-04-04 Bill Soudan <so...@kd...>
Reverted my previous commit.
|
|
From: Jonas S. <jon...@ki...> - 2001-04-03 22:44:15
|
I'm looking for some rudimentary info on using icqlib, - which functions to call to set it up, and in which order, - how the various structs fit in, - how to implement the callbacks -- the basic philosophy of the library -- I tried looking at the early versions of kicq, but I suppose that icqlib has changed substantially since the early versions of kicq? Btw, BeOS is my target platform. (Icqlib was ported to BeOS by Bill Soudan.) TIA, Jonas Sundstr=F6m. www.kirilla.com |
|
From: Henric L. <h-...@ak...> - 2001-03-28 17:54:04
|
Hi, I'm trying to do some work on the miranda codebase. but I can't figure out how to do automatic resend of packages that doesn't get ACK'ed by the server. I think the icqlib is the same as 1.0.0 but I'm not sure. --> hen...@wi... <-- |
|
From: Lars C. <la...@cs...> - 2001-03-26 19:33:23
|
Why the restriction that UDPSok cannot be less-than or equal to 3 in udp.c? UDPSok is == 3 if you disable TCPSupport! stdin, stdout and stderr take up 0 1 2 if that's what you think about, but this is not really define anywhere anywere in a standard. socket() can return anything >= 0 which is useable, so you should probably apply this to udp.c: 138c138 < if(icqlink->icq_UDPSok <= 3) --- > if(icqlink->icq_UDPSok < 0) -- Lars Christensen, la...@cs... |
|
From: Bill S. <we...@ri...> - 2001-03-26 05:23:43
|
On Sun, 18 Mar 2001, Lars Christensen wrote: > I am receiving segfaults in the tcplink code. May be you have a > clue. I try to initiate a file transfer with icq_SendFileRequest(), > and then immediatly, both my two client segfault. > > Any ideas? Looks related to all the rearranging I've been doing lately :) I'll take a look at it more carefully sometime this week, I hope. > Btw... icqlib does not really compile right now without the > ChatRusConv stufff being commented out. Working on that, too, hopefully I'll have a fix in tonight. Bill |
|
From: Bill S. <we...@ri...> - 2001-03-26 05:21:40
|
On Tue, 13 Mar 2001, Lars Christensen wrote: > Lars Christensen <la...@cs...> writes: > > > The attached patch added handling of packet types 0x01e0 and 0x1ea, > > which notifies the client of the result of a "basic info" update. > > Ok. That was less than succesfull. Here is the corrected path with > icq.h.in patched too :-) Thanks for the patch, it's on my TODO list. :) Bill |
|
From: Bill S. <we...@ri...> - 2001-03-25 21:21:01
|
On Fri, 23 Mar 2001, Eric Peyton wrote: > Got another question for you fine folks. > > OS X is a fully Unicode and UTF-8 aware OS. I currently pass all strings > as UTF-8 and pass the UTF8String to you all, expecting that on the other > end "the right thing" will happen. > > Of course, it doesn't. All my foreign users (i had six complaints this > morning on this) complain about the fact that their umlaut and local > characters get trahsed when sent across icq. > > Does icqlib have a way of handling this? Is there a special library I > need? Hi Eric, Interesting you should mention this, currently I'm hacking the encoding support in icqlib. This is the first I've ever worked with character encodings, so bear with me :) The ICQ protocol uses the Windows codepages to encode strings, not UTF-8. Unix, of course, uses a different set of codepages. Icqlib has always had support to translate between Unix's Cyrillic codepage (koi8-r) and Window's Cyrillic codepage (Windows 1251) since Denis speaks Russian, and just recently I added support for the Czech encodings from a patch that was submitted. Those are the only two translations we support right now. You'll need to translate the UTF-8 strings before you pass them to icqlib, because icqlib is expecting the standard Unix ISO-8859-* encodings. Another (probably better) idea would be to add direct UTF-8 <-> Windows codepage translation code, and then icqlib would support Unicode natively, which would be excellent! I was thinking about this while working on the encoding support. After looking around just now a bit, it looks like glibc has some conversion functions you can use, look for 'iconv'. Maybe we can switch to using this in icqlib too, then we'll support many, many encodings. I don't have time to do this myself right now, and it will likely be a few months before I could get to it, but I'll put it on my TODO list. Of course, we'd gladly accept a patch too! Bill |
|
From: Lars C. <la...@cs...> - 2001-03-18 00:03:42
|
Hi.
I am receiving segfaults in the tcplink code. May be you have a
clue. I try to initiate a file transfer with icq_SendFileRequest(),
and then immediatly, both my two client segfault.
The sender of the request has this traceback:
#0 0x80583d3 in _icq_SocketHandleReady (p=0x403c6fec,
data=0xbffffa6c)
at socketmanager.c:212
#1 0x8050be8 in icq_ListTraverse (plist=0x402d5ff0,
item_f=0x80583b0 <_icq_SocketHandleReady>) at list.c:190
#2 0x805847a in icq_SocketPoll () at socketmanager.c:232
#3 0x804fdaf in icq_Main () at icqlib.c:241
And the receiver this traceback:
#0 0x8053283 in icq_TCPLinkProcessReceived (plink=0x403d9fa8) at
tcplink.c:857
#1 0x8051be0 in icq_TCPLinkDelete (pv=0x403d9fa8) at tcplink.c:95
#2 0x8051d17 in icq_TCPLinkClose (plink=0x403d9fa8) at tcplink.c:140
#3 0x805bcf6 in icq_TCPProcessHello (p=0x40417ff0, plink=0x403d9fa8)
at tcphandle.c:212
#4 0x80532c5 in icq_TCPLinkProcessReceived (plink=0x403d9fa8) at
tcplink.c:864
#5 0x8052c7c in icq_TCPLinkOnDataReceived (plink=0x403d9fa8) at
tcplink.c:687
#6 0x805827a in icq_SocketReady (s=0x40413fec, type=0) at
socketmanager.c:166
#7 0x8058416 in _icq_SocketHandleReady (p=0x40413fec,
data=0xbffffa9c)
at socketmanager.c:213
#8 0x8050be8 in icq_ListTraverse (plist=0x402f5ff0,
item_f=0x80583b0 <_icq_SocketHandleReady>) at list.c:190
#9 0x805847a in icq_SocketPoll () at socketmanager.c:232
#10 0x804fdaf in icq_Main () at icqlib.c:241
What is odd in frame 8 of this last traceback is that frame 7 is
called with a pointer that is not in the list:
(gdb) print plist->head->item
$22 = (void *) 0x40310fec
(gdb) print plist->head->next->item
$23 = (void *) 0x40314fec
(gdb) print plist->head->next->next
$24 = (struct icq_ListNode_s *) 0x0
Any ideas?
(linking with efence is helpfull in this case, i think)
Btw... icqlib does not really compile right now without the
ChatRusConv stufff being commented out.
--
Lars Christensen, la...@cs...
|
|
From: Bill S. <we...@ri...> - 2001-03-08 04:12:13
|
On Wed, 7 Mar 2001, Michael Hudson wrote: > Does it work? When I use the wrong password and jack the log level > up, I get things like: > > 983985046 '\003' Unhandled protocol version! Message 7800, Version: 3, Sequence: e5a5, Size: 16 > > and my WrongPassword method never gets called. Not sure about this one, UDP is Denis' area. I'm fairly sure it worked at one point, so maybe it was broken when he upgraded UDP from v3 to v5. Denis? :) Bill |
|
From: Bill S. <we...@ri...> - 2001-03-08 04:10:07
|
On Wed, 7 Mar 2001, Michael Hudson wrote: > Bill Soudan <we...@ri...> writes: > > > 2001-03-06 Bill Soudan <so...@kd...> > [...] > > * icqlib/icqlib.c, icqlib/icq.h.in: [...] removed > > ICQLINK parameter from icq_Main. > > Pop trivia: > > What's the difference between > > void icq_Main(); > > and > > void icq_Main(void); > > ? (Hint: there isn't one in C++). > > Fixed. You know, after years of programming, I never knew that until just a few weeks ago. Probably cause I try to spend more time in C++ than C... Noticed you fixed up the Python bindings already too, was going to do that tonight, thanks! Bill |
|
From: Michael H. <mw...@ca...> - 2001-03-07 17:11:54
|
Does it work? When I use the wrong password and jack the log level
up, I get things like:
983985046 '\003' Unhandled protocol version! Message 7800, Version: 3, Sequence: e5a5, Size: 16
and my WrongPassword method never gets called.
TIA,
M.
--
ARTHUR: Why should a rock hum?
FORD: Maybe it feels good about being a rock.
-- The Hitch-Hikers Guide to the Galaxy, Episode 8
|
|
From: Michael H. <mw...@ca...> - 2001-03-07 12:35:42
|
Bill Soudan <we...@ri...> writes:
> 2001-03-06 Bill Soudan <so...@kd...>
[...]
> * icqlib/icqlib.c, icqlib/icq.h.in: [...] removed
> ICQLINK parameter from icq_Main.
Pop trivia:
What's the difference between
void icq_Main();
and
void icq_Main(void);
? (Hint: there isn't one in C++).
Fixed.
Cheers,
M.
--
> Why are we talking about bricks and concrete in a lisp newsgroup?
After long experiment it was found preferable to talking about why
Lisp is slower than C++...
-- Duane Rettig & Tim Bradshaw, comp.lang.lisp
|
3 messages has been excluded from this view by a project administrator.
