Problems with communication
wydesenej
i try to develop QT/C++ library for OSCAR protocol. Now, I have a
problem with communication. When I send this SNACK:
http://iserverd.khstu.ru/oscar/snac_01_17.html to server connection
with server is closed. Pls help!
Here part of communication (its outup of my software but i hope that
is simple):
<<<<<IN<<<<<<
CHA: 2
SQN: 54961
LEN: 38
DATA:
-----------------------------------------------
00 01 00 03 00 00 c6 04 3c e0 00 01 00 02 00 03
00 04 00 06 00 08 00 09 00 0a 00 0b 00 0c 00 13
00 15 00 22 00 25
-----------------------------------------------
-------SNACK INFO-------
FAMILY : 1
SUBTYPE: 3
FLAGS : 0
REQ_ID: 4294967295
DATA :
00 01 00 02 00 03 00 04 00 06 00 08 00 09 00 0a
00 0b 00 0c 00 13 00 15 00 22 00 25
-------/SNACK INFO-------
>>>>>OUT>>>>>
-----------------------------------------------
2a 02 00 05 00 32 00 01 00 17 00 00 00 00 00 17
00 01 00 04 00 02 00 01 00 03 00 01 00 04 00 01
00 06 00 01 00 08 00 01 00 09 00 01 00 0a 00 01
00 0b 00 01 00 13 00 04
-----------------------------------------------
###Connection lost
Alex Rass
Does anyone know (or wants to know) joscar well enough to help me make it
better?
I am willing to put money behind it. (Pay you for your time).
Let me know.
- Alex.
Alex Rass
I am not familiar with Mina, but here are the issues we are having with
jOscar:
Its' CRAZY flexible. It's fantastic. Adding new features is really easy,
from what I hear from guys who have had to do it in the past.
It supports ICQ and AIM nicely.
There are couple of layers, as you probably know:
The raw socket stuff, flaps, snacs and all. (lets call it transport)
The wrapper classes that are aware of them. (lets call it base layer)
Nice app layer which knows which wrapper to use and how and has some sort of
model behind it for the features. (lets call it application/app layer).
Problem is that there are a ton of features which aren't wrapped in the base
layer, let alone app layer. And even things that are done in app layer are
often incomplete for even a simple implementation. This needs to be
finished/updated (in some random priority).
The base layer d/n handle timeout properly. There's a flap(5) sent out every
3 min, but if other end drops connection w/o closing a socket - we don't
know to reconnect. (I had to hack for that to work properly). This is a
problem for obsessive firewalls.
The protocol in jOscar doesn't follow the proper order of things compared to
other aim clients. So there are a number of logging/monitoring tools which
don't work with jOscar. (not deadly, but annoying cause some companies can't
use jOscar based products b/c their proxy-like monitor servers can't connect
properly. (This is the least of my problems actually, just including it for
completeness)
I can see you guys have your own list of stuff too. Which is great.
One of my clients said they'll pay for fixing the delete users bug (there's
no call in buddyList to delete users. So I've been using a base layer
approach to do it. Which is causing compatibility problems after someone
made some changes. It's clashing with some other listener.
Another thing my client wants fixed are the timeouts/connectivity issues.
Right now not only you can sit there disconnected and not know about it, but
you can even send a message and it d/n tell you that no server is receiving
it. Which is frustrating and terrifying.
I know these are only a few small problems, but hey - you guys need other
work on the protocol done anyway, think of these as donations to the cause
;) Maybe it'll buy you some hardware that you need or pizza.
So, in case you were wondering - yes jOscar is used. It's great. It just
needs a tuneup (Mina?), updates, and we can't always dump everything on
Keith.
I would be happy to assist in testing of the new version.
I also have a full Swing UI and a simple web client to the protocol. So you
can have immediate userbase.
- Alex.
-----Original Message-----
From: Ariel Amato [mailto:ariel.a...@gmail.com]
Sent: Friday, October 31, 2008 11:21 AM
To: Alex Rass
Subject: Re: [joscar-discuss] Paid work with JOscar
Alex,
We know that jOscar works, the main reasons we have to do a
different implementation are the following:
* We are using Apache Mina to implement our nio layer
in most of our libraries, with good results.
* It's sometimes very unclear and difficult to follow
how the packets are created and sent to AIM/ICQ.
We also know that Oscar is not the most simple protocol and
that jOscar has a lot of hard work already done, so reuse of jOscar
code is a must.
Our idea was this:
Use Mina as the NIO layer.
Reuse or adapt the protocol parser/serializer.
Review the packet architecture to see if there is a
way to simplify it.
Check what other packets/commands are needed to
implement missing functionality.
Maybe it was a bad choice of words to say that we wanted to create a
new library, since it would be clearly an evolution of jOscar.
Looking forward to hear your opinion.
Ariel