in reply to Re: Aci Base24-eps (on IBM AIX)
in thread Aci Base24-eps (on IBM AIX)

Hi Corion,

My code snippets follows

Client code snippet...

$socket = IO::Socket::INET->new(PeerAddr => '77.77.77.77', PeerPort => 1500, Proto => 'tcp') or die "Couldn't connect to remote server\n";<br><br> $socket->autoflush(1);<br><br> .....<br><br> .....<br><br> my $tcpmessage = realencodeData($mti) . $PrimaryBitmapHex . $dataelem +ent . "\n";<br><br> $socket->autoflush(1);<br> print $socket $tcpmessage;<br> $socket->autoflush(1);<br><br><br><br><br>
Server code snippet...

# initialize host and port<br> $socket = IO::Socket::INET->new(Proto => 'tcp', LocalPort => 1500, Lis +ten => SOMAXCONN, ReuseAddr => 1, Reuse => 1) or die "Couldn't +connect to port:\n";<br><br> warn "Waiting for incoming connections on port 7535...\n";<br><br> while (!$quit)<br> {<br> $socket->autoflush(1);<br> next unless my $session = $socket->accept;<br><br> my $peer = gethostbyaddr($session->peeradd, AF_INET) || $session-> +peerhost;<br> my $port = $session->peerport;<br> warn "Connection from ($peer, $port)\n";<br><br> $session->autoflush(1);<br><br> while (<$session>)<br> {<br> $session->autoflush(1);<br> chomp;<br> print $_ . "\n";<br> parsemessage($_);<br> }<br> warn "Connection from ($peer, $port) finished\n"; close $session;<br> }<br><br> warn "Closing connection(s)...\n";<br><br>

Replies are listed 'Best First'.
Re^3: Aci Base24-eps (on IBM AIX)
by gman (Friar) on Mar 01, 2010 at 15:07 UTC

    I'm unfamiliar with Base24-eps, is it ACSII based? I would think you have to determine the record terminator or record byte length.

      Base24-eps data transmission is purely ASCII, but I dunno if there is any record length marker preceding the message, neither am I sure if there is any record length terminator after the message. I checked the manual and couldn't find either.

      Interestingly, WireShark was able to 'see' and parse the incoming B24-eps data while my own application was totally blind to it.

      Any ideas?

        You read from $session line-by-line, but you never send a newline.

Re^3: Aci Base24-eps (on IBM AIX)
by BrowserUk (Patriarch) on Mar 02, 2010 at 01:16 UTC

    Try setting  $/ = \1;, that will cause your code to get 1 character at a time and at least show you that it is receiving something (or not).

    Once you see that you're receiving stuff, you can try adjusting it (say: $/ =\4;) and maybe it'll allow you to work out how the packets are delimited.

    Mind you, you ought to be able to work that out from the wireshark traces you mentioned.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      Thanks BrowserUK, your code works like charm, however, I now have this knotty problem - socket headers. How can I force the socket NOT to send header information? The Base24-eps trace log is capturing the header info sent by the socket and junking my iso8583 messages. The socket headers are being sent by the socket captures the destination, my ip, sending port and other info.

        Glad to have helped--but I'm not sure if I can be of much further help. All I know of your problem is what I've just read as a result of your mentioning ISO-8583.

        How can I force the socket NOT to send header information? The Base24-eps trace log is capturing the header info sent by the socket and junking my iso8583 messages.

        I think you may have some quite deep misunderstandings of what you are dealing with. (Or they could just be my misunderstandings! Consider yourself warned:)

        Sockets don't "send header information". Tcpip wraps data sent via sockets into 'packets', which include headers that carry your IP. But there is no way to turn these off, because without them, your data would never reach its destination. Consider those wrappers like the envelope in which you put a note to your mother: "Dear Mum, I won't be home until friday. Love Naija". Post that note in a postbox without an envelope carrying your mother's address, and there's no way she's ever going to get it.

        But the point is, you don't need to prevent the headers being transmitted, because they will be stripped away by the tcpip stack at the other end, before your server ever sees them!.

        I think the reason your "Base24-eps trace log" (which you alternatly referred to as "the runtrc log" in a /msg), is because whatever that tool is, it is running at one level (or more) below the socket layer of the tcpip stack on the server. Essentially, you are looking in the wrong place to see what your server is actually receiving via the socket at it's end.

        It would be useful (ie. might get you more responses from those that know), if you posted the (few lines) of code where you first construct, and then send the packet to the server. This might allow someone to diagnose your problem further.


        As an aside, if you are not already locked in to Perl for the work you are doing, you might consider using another language. At the bottom of the wikipedia page I linked above, there is a list of links to language binding to ISO-8583, unfortunately Perl is conspicuous by its absence. But python, Ruby and PHP all show up there, along with the heavyweights of Java and .NET

        Alternatively, if you have the skills, or the money to purchase them, you might consider writing a Perl wrapper package around the OSS C implementation listed there, and contribute it to CPAN so other Perlers don't face the same dilemma.


        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.