Re: SAR

RE: SARHi Damir/Igor,

As you have seen, my implementation is done based on State Machine in WTP Response Layer. Also to my knowledge, I implemented all the functionalities in SAR (Segmentation/Re-Assembly/NACK/ACK). 

One thing I like to ask from Igor is is there any efficiency problem or anything when you do it using the Sate Machines?

The problem was with my implementation is little funny one. Actually I'm not sure if that's cause of a bug in the SAR implementation or related to some other part. The problem was, when a phone initiate a WAP session, WTP state changes to INVOKE_RESP_WAIT and waits for a Response from WSP layer. And this continues for a long time or indefinitely. Also this problem occurs only occationally. The funny thing here is, this happens prior to the start of SAR packets, so I guess this couldn't be because of my coding. Igor, I know you are in a much greater level to understand what this problem can be. Please help me to sort this.

If any other person has tried my coding please give me your comments.

Thanks,
Denzel

  ----- Original Message ----- 
  From: Igor Ivoilov 
  To: '[email protected]' ; [email protected] 
  Sent: Thursday, December 05, 2002 4:53 AM
  Subject: RE: SAR


  Hi Damir, 

  You're right, this thing is not implemented, 
  but the implementation is coming soon 

  Igor 

  > -----Original Message----- 
  > From: Damir Salantic [mailto:[email protected]] 
  > Sent: Thursday, December 05, 2002 12:06 PM 
  > To: [email protected] 
  > Subject: SAR 
  > 
  > 
  > Hi to all. 
  > 
  > I started to work with kannel recently, so excuse me for my 
  > ignorance, if 
  > I'm wrong. 
  > I'm refering to "SAR" thread one month ago. 
  > 
  > Denzel wrote on Nov. 13.: 
  > "Here's a SAR patch we made ( diffrent to Igore's). We tested 
  > this with = 
  > an earlier CVS ( may be in sync with gateway1.2.0 ). Nack's are = 
  > implemented.  And we had a problem with igore's patch, cause 
  > sometimes = 
  > the nacks failed ." 
  > 
  > Igor wrote on Nov. 13.: 
  > "Nack reaction was not implemented in early version of sar.patch. But 
  > version 
  > that's come to cvs has this feature." 
  > 
  > Now I'm looking on both versions: one with Denzel's patch and 
  > the one from 
  > CVS. 
  > What I see is that in CVS version there is implemented only 
  > response to NACK 
  > and not a NACK request. In another words, CVS Kannel doesn't 
  > take care about 
  > lost wtp segments and never sends NACK to the sender, but only ACK. 
  > This can be seen in following code: 
  > 
  > wtp_resp.c line 722: 
  > 
  >         if (orig_event->u.RcvSegInvoke.gtr == 1) { /* Need to 
  > acknowledge */ 
  >             e = wtp_pack_sar_ack(ACKNOWLEDGEMENT, machine->tid, 
  > machine->addr_tuple, 
  >                                  orig_event->u.RcvSegInvoke.psn); 
  >             dispatch_to_wdp(e); 
  >         } 
  > 
  > and when receives incomplete packet it just reports debug info: 
  > 
  > wtp_resp.c line 793: 
  >     for (i = 1; i <= last_psn; i++) { 
  >         if ((sar_info = list_search(machine->sar_info, &i, 
  > is_wanted_sar_data)) != NULL) { 
  >             
  > octstr_append(e->u.RcvInvoke.user_data,sar_info->sar_data); 
  >         } else { 
  >             debug("wap.wtp", 0, "Packet with psn %d not found", i); 
  >             return e; 
  >         } 
  >     } 
  > 
  > In Denzel's implementation it seems to be solved correctly 
  > (wtp_check_segments). 
  > 
  > Igor, can you confirm that, so I should use Danzel's patch 
  > instead of CVS. 
  > Do you plan to implement that also? 
  > Maybe some part from Denzel's patch can be integrated to CVS? 
  > 
  > Thanks 
  > Damir Salantic 
  > 
  > 
  > 
  >