Re: Question about dlr_add and dlr_find parameters

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]
>
>
>
>