|
はじめまして、tomtom といいます。 ソケット通信に興味があり、勉強に励んではや３ヶ月の初心者です。 最近、自分で簡単なクライアントサーバのソケット通信プログラムを 作成してみたのですが、recv関数で受信エラーが発生してしまいます。 メッセージの送信元で、send関数により送信された内容と、 実際にrecv関数で受信した内容を確認してみたところ、きちんと 同じものが受信できているようでした。 そこで、エラー番号から何がおきているのか解析しようとしたのですが、 やり方が間違っているのかエラー番号を何も出力してくれません。 もし、何かお気づきのことがあるようでしたら、 ご指導いただけないでしょうか？ 問題の箇所： if(recv($sock_id, $msg, $MAX_BUFF, 0) eq undef){ print "$msg"; print "errno = $!"; } |
|
度々すみません。 先ほど投稿させていただいたtomtomです。 処理系を書き忘れたので，再度書き込みをさせていただきました。 動かしている処理系は、linuxです。 余談ですが、linux-perlとactive-perlとで、recvやsendなどの システムコールの処理結果は、異なるのでしょうか？ （NG時undefを返さず、別のものを返す、、など） クライアントをlinux-perlで、サーバをactive-perl(WinXP)で 起動しおり、サーバの方は、同様のrecv記述で上手く受信できているの で、なにか関係あるのかな、と素人ながら少し気になりました。 以上、度々失礼しました。 |
|
>>3315 tomtom > if(recv($sock_id, $msg, $MAX_BUFF, 0) eq undef){ undef かどうかのチェックは、正しくは if ( ! defined recv($sock_id, $msg, $MAX_BUFF, 0) ){ です。recv は相手側のアドレス (IP アドレス+ポート番号) を 返すので、それが undef と一致する、と解釈されているのかも しれません。 # でも、この書き方では undef を返さない限り eq undef と # ならないような気がするなぁ。 >>3314 mikan > いざメールを使用してみると、パスワード認証エラーがでて > はじかれます。 メールを使用というのは、POP を使ってメールを取得してみた ということですか? もしそうなら、telnet で POP サーバに アクセスし、本当に認証エラーになっているのか調べてください。 http://x68000.startshop.co.jp/~68user/net/pop3-1.html あと、ユーザ追加だけで OK か、というのは職場のメールサーバの 設定次第なので何とも言えません。 |
|
tomtomです。 68userさん、アドバイスをありがとうございます。 自分が素人であることを実感いたしました。 undefを判別するのには、define関数をもちいるのですね。 アドバイスに感謝いたします。 早速、試してみますね。 ではでは |
|
perlでテキスト処理をしていますが、有るリストをキーとしたハッシュ を生成したんですが、そのキーとなるファイルのサイズが110Mb程、キー数 (レコード数)は約1000万弱のレコードが有ります。 そのハッシュのキーを使い別のCSVのフィールドの中に同じキーが存在 する場合に必要な処理を行なっています。 if(exists $KEY{$csv_key_field}){ 処理 } で、実際に動かすと500Mbのメモリを使い切り(何故？)、1Gbのスワップ さえも使いきり止まってしまいます。 根本的にこのアルゴリズム自体が悪いのか、それとも何かメモリ使用量を 抑える解決方法があるのか教えてください。 ちなみに、キーとなるデータを配列に格納して grep で検索するとさらに べらぼうに時間が掛かります。 具体的には2つのリストの合成処理なんですが、このくらいの規模になると DBに置き換えて処理した方が良いのでしょうか？ (最終的には何らかのDBに格納されるそうです) もちろん、変数は可能な限り局所化しています。(つもりです(^^;) もっと言えば、上記は最大サイズのリストではありますが、キーリストは 複数あり、それらを順繰りに処理しています。 どうぞお助けくださいm(_ _)m |
|
>>3319 スナフキン > そのキーとなるファイルのサイズが110Mb程、キー数(レコード数)は > 約1000万弱のレコードが有ります。 全体のデータ容量がわからないですが、仮に 300MB 程度だとしても、 1.5GB 喰い尽くしてもおかしくないかなぁとは思います。 perl の内部構造は知りませんが、スカラー 1つ、配列の一要素、 ハッシュ 1キーなど、それぞれに必ず何バイトかずつ管理用データを perl が保持しているからです。 実感としては、100MB 程度でもデータの持ち方次第ではまともに 動かないこともあるんじゃないかと思います。 > このくらいの規模になるとDBに置き換えて処理した方が良いので > しょうか？ perl でもがんばれば何とかなるかもしれませんが (実データはファイルに 保存し、ハッシュにアクセスされるたびに tie でそのファイルを見にいくとか)、 1. データが固定長 (もしくは最大長が決まっている) 2. CSV の項目名や項目長が変わる可能性は少ない 3. 処理内容が変わる可能性が少しでもある (この条件に引っかかるレコードは除外する、とか) であれば、DB に突っ込んだ方がよろしいのではないでしょうか。 わたしならそうします。 項目名や項目長も変わるかもしれないなら、DBD::CSV モジュールとか (使ったことないですけど)。 |