Re: [Jnetstream-users] jNetStream 2.4 extension: multi packets TCP reassembly needs for global static variable

[Mark B. <voy...@ya...>]

There is already a mechanism in 2.4 for this. The NPL statement is "buffer".
Here is an extract of a working example. IP reassembly, but same concept can
be applied to TCP. This is from a working IPv4 NPL definition:

http://jnetstream.cvs.sourceforge.net/viewvc/jnetstream/jnetstream/config/pr
otocols/network/IPv4.npl?view=markup

	if ( (flags.mf == flags.mf.MORE_FRAGS) || (offset != 0) ) {
  452 		/*
  453 		 * Since this is a multi fragment message, put remainder
  454 		 * of the data into the buffer identified by "ip.identifier"
  455 		 * and write data starting at offset. Reads until the end of
  456 		 * the current packet.
  457 		 *
  458 		 * packet.remainder = remaining number of bytes in current
packet
  459 		 * -2 = subtract Ethernet CRC at the end of the frame.
  460 		 * offset = ip.offset which specifies the offset into the
buffer
  461 		 *          to start writting at. Packets could arrive out
of seq.
  462 		 *
  463 		 * buffer reread = start buffering while pushing the current
position.
  464 		 *               Rewind the stream back to here and
reprocess the
  465 		 *               rest of this packet so that all headers in
this
  466 		 *               fragment packet are complete as well. This
means
  467 		 *               that fields are going to be decoded twice
  468 		 *   1) for this packet
  469 		 *   2) when reassembly takes place on the buffer.
  470 		 */
  471 		buffer reread id, offset * 8, 0;
  472
  473 	}
  474
  475 	if (flags.mf == flags.mf.NO_MORE_FRAGS) {
  476 		/*
  477 		 * Now process the buffer as if it were a new packet. The
current
  478 		 * processing is temporarily suspended and resumed right
after the
  479 		 * buffer processing is finished.
  480 		 *
  481 		 * The new packet which results from the buffer data is
queued to
  482 		 * be returned right after this fragment is returned. That
is on
  483 		 * the next nextPacket() call the decoded buffer packet is
returned.
  484 		 *
  485 		 * identifier = buffer identifier (i.e. ip.identifier)
  486 		 * protocol.valuename = name of the first protocol in this
buffer which
  487 		 *                   we take from the IP fragment protocol
name.
  488 		 */
  489 		buffer process id, protocol.valuename;
  490 	}

As to global variables, you can already set any arbitrary variable in any
context, global, packet or local.

Cheers,
mark...



> -----Original Message-----
> From: zosrothko [mailto:zos...@or...]
> Sent: Wednesday, October 01, 2008 1:04 PM
> To: jne...@li...
> Subject: [Jnetstream-users] jNetStream 2.4 extension: multi
> packets TCP reassembly needs for global static variable
>
> Hi Mark
>
> I am currently working on the OSI protocol dissectors and I
> got a problem with the RFC1006
>
> When a RFC1006 payload is fragmented over multiple TCP
> packets, there is no way to understand when the reassembly
> process should be finished and the overall buffer passed to
> the upper layer. That is why I am proposing you to introduce
> in NPL, global static variable that can cross (i.e.
> survive/persist) over packets.
>
> One could use this kind of static variable in order to
> reassemble the fragmented packet payload much as like you
> have done with the IP fragmentation case.
>
> IMHO, just adding the modifiers 'static' and 'global' would
> be a good way to denote this feature for the already
> available variable syntax, but I do not have enough knowledge
> of jNetStream to propose you a patch for its implementation.
>
> Cheers
>
> zos
>
>
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move
> Developer's challenge Build the coolest Linux based
> applications with Moblin SDK & win great prizes Grand prize
> is a trip for two to an Open Source event anywhere in the
> world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Jnetstream-users mailing list
> Jne...@li...
> https://lists.sourceforge.net/lists/listinfo/jnetstream-users