Re: Question about dlr_add and dlr_find parameters

Please check on my latest patch over the "smsc-dlr-alias" parameter.  
To use the dlr_alias, it modifies the code on the smsc's that were  
using the ->name instead of ->id to be as follows:

  -        msg = dlr_find(conn->name, timestamp, destination, code);
+        msg = dlr_find((conn->dlr_alias ? conn->dlr_alias : conn- 
 >name), timestamp, destination, code);

conn->dlr_alias, if undefined, gets loaded with conn->id.

Regards,
--
Alejandro Guerrieri
[email protected]



On 04/05/2009, at 19:58, Andreas Fink wrote:

> in all cases the conection name,is being passed. If I remember right  
> it was mainly used for logging purposes.
> apparently there where cases in EMI where conn->id was empty or so.
> unifying it would make sense in my eyes.
>
> Note: I wrote the initial implementation in SMPP and EMI/UCP. The  
> CIMD2 and OISD implementations where probably added way later by  
> someone else who wasnt considering the connection struct could be  
> empty. Not sure when this can be but I guess this might be the case  
> on incoming EMI/UCP connections to the incoming port. In contrary to  
> the other protocols, EMI/UCP supports a incoming listener while in  
> SMPP, the incoming packets come on a outgoing TCP connection doing a  
> bind receiver (or bind transceiver). In EMI it can be done the same  
> (in large account mode) but simpler  EMI implementations had a  
> outgoing connection from the SMSC to Kannel.
>
> On 04.05.2009, at 19:02, Alejandro Guerrieri wrote:
>
>> Hi,
>>
>> Just a quick question: I'm checking on different smsc's  
>> implementations and I've noticed that, despite that dlr_add and  
>> dlr_find are usually called using conn->id for the first parameter  
>> (smsc), on some smsc's conn->name is used instead:
>>
>> gw/smsc/smsc_cimd2.c:	dlr_add(conn->name, ts, msg);
>> gw/smsc/smsc_emi.c:		dlr_add((conn->id ? conn->id : privdata- 
>> >name), ts, m);
>> gw/smsc/smsc_oisd.c:	dlr_add(conn->name, ts, msg);
>>
>> Does anybody know if is there any reason for this or is it just a  
>> different implementation?
>>
>> Would it make any sense to change it to be in line with the rest?
>>
>> I guess it makes sense to use conn->id since it's user-definable,  
>> though conn->name is generated from the connection parameters  
>> (host, port, user), though limiting what can be done with it (for  
>> example: two different binds wouldn't be able to manage dlr's from  
>> each other).
>>
>> Regards,
>> --
>> Alejandro Guerrieri
>> [email protected]
>>
>>
>>
>>
>
>