WindowsのSocket(TCP)

WindowsのSocketはAPIに変遷の歴史があり、ちょっと苦手です。（最初に作った時は、まだWinSock(1)のころで、Linuxとかなり似たAPIでした。その後、WinSock2になり、M$は.NetやMFCを推奨してきて嫌になります）
QtのSocketクラスを使えば、その辺をラップしてくれて楽ができます。ちょっと試しにServerのconsoleプログラムを作ってみました。telnet等をclientにして簡単に実験ができます。

proファイルですが、networkの追加を忘れずに。

MyTcpServer.pro

QT -= gui
QT       += core
QT       += network

CONFIG += c++11 console
CONFIG -= app_bundle

mainは以下の通りです。

main.cpp

#include <qcoreapplication>
#include "mytcpserver.h"

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    MyTcpServer server;

    return a.exec();
}

MyTcpServerクラスのヘッダは最低限の関数だけ定義します。

mytcpserver.h

#ifndef MYTCPSERVER_H
#define MYTCPSERVER_H

#include <qobject>
#include <qtcpsocket>
#include <qtcpserver>
#include <qdebug&gt

class MyTcpServer : public QObject
{
    Q_OBJECT
public:
    explicit MyTcpServer(QObject *parent = 0);

signals:

public slots:
    void newConnection();
 void readData();
 void socketError(QAbstractSocket::SocketError);
 void deleteLater();

private:
    QTcpServer *server;
 QTcpSocket *socket;
};

#endif // MYTCPSERVER_H

本体です。connectして文字列を送ったら、後は受信するだけのものです。相手がcloseしたり、勝手に切ったり、エラーが起きたらServer側はcloseするようにしてあります。また、"bye"を受信したらやはりcloseします。（windowsだと、受信文字列の最後にCR/LFが含まれますが、Linux等では行末記号は含まれてきません。）

mytcpserver.cpp

// mytcpserver.cpp

#include "mytcpserver.h"
#include <qdatastream .h>

MyTcpServer::MyTcpServer(QObject *parent) :
    QObject(parent)
{
    server = new QTcpServer(this);

    // 誰かがconnectしてきたら、signalを出してnewConnection()をCall
    connect(server, SIGNAL(newConnection()),
            this, SLOT(newConnection()));

    if(!server->listen(QHostAddress::Any, 9999))
    {
        qDebug() << "Server could not start";
    }
    else
    {
        qDebug() << "Server started!";
    }
}

void MyTcpServer::newConnection()
{
    // socketのインスタンスを生成
    socket = server->nextPendingConnection();

 qDebug() << " connect";

 // 切断した時の処理を定義
 connect(socket, SIGNAL(disconnected()), socket, SLOT(deleteLater()));

 // 受信した時の処理を定義
 connect(socket, SIGNAL(readyRead()), this, SLOT(readData()));
 // エラー処理の定義
 connect(socket, SIGNAL(error(QAbstractSocket::SocketError)), this, SLOT(socketError(QAbstractSocket::SocketError)));
 // 切断したときの処理としてSLOT関数を設定する。
 connect(socket, SIGNAL(disconnected()), this, SLOT(deleteLater()));

 // クライアントのIPアドレスを取得
 QString ippaddr = socket->localAddress().toString();

 // 送信データをstreamとして定義
 QDataStream out(socket);
 out.setVersion(QDataStream::Qt_5_0);

 out << "Hello client\r\n";
 
}

void MyTcpServer::readData()
{
 QString s;

 // 受信データを」streamとして定義
 //QDataStream in(socket);
 //in.setVersion(QDataStream::Qt_5_11);

 //in >> s;

 s = socket->readAll();

 qDebug() << "receive : " << s << "( " << s.size() << " ) ";

 if ("bye\r\n" == s)
 {
  qDebug() << "close process";

  //deleteLater();
  emit socket->disconnected();
 }

}

void MyTcpServer::socketError(QAbstractSocket::SocketError )
{
 qDebug() << " socket error!";

 socket->close();
}

void MyTcpServer::deleteLater()
{
 qDebug() << " socket disconnected";

 socket->close();
}

さて、ここでこのサンプルを作った本題に入ります。前からLinuxでSocket(TCP)のプログラムで悩んでいたのが、通信しているプログラムの片方が、socketをつないだまま、異常終了すると、しばらくその時のportが使えなくなる現象に困っていました。一方、昔winsockを見ていた時、windowsのAPIには、portを強制的にconnectするというフラグがあり、どう違うのか疑問に思っていました。
このサンプルプログラムで、windowsとLinux(or Mac)での挙動の違いを調べてみました。

(1)通信中にServerを強制終了すると、Linux(Mac)ではやはり当該portは使えなくなります。（already useのエラーメッセージがでます）しかし、windowsは何事もなかったようにconnectできます。
(2)Linux(Mac)でも、client側が強制終了しても、サンプルのServerでは相手との通信が切れたことを検知して、portをcloseするようにしてあるので、再度clientは接続できます。（これまでLinuxでうまくいかなかったのは、この処理を入れてなかったことに気づきました）

Windowsは「楽観的」というか「危険」というか、考え方がかなり違います。

Visual StudioでのPython（win10でのpython環境）

いつの間にかVisualStudio上でpythonが開発できることに今更気づきました。このところVSCodeでpythonのデバッグ環境を作っていたので、これなら本家のVisual Studioだってできるだろうと思いつき、調べてみたら2013くらいからできるようになったようです。

win10上でのpython環境は、Visual StudioではPython Toolsのパッケージをインストールしないとデバッグできませんが、pythonインタープリタ自体は自分で好きなものをインストールしろとのこと。runtimeには含めていないようです。配布を考えると、どっちが楽なんだろうか微妙なところですが、これまでwindowsではpythonはメジャーではなかったし、元々OS非依存で開発されていましたからこんな形になったんでしょう。

うちにある最新のwin10マシンにはVisual Stuido 2017 Communityが入れてありますが、真っ先にAnacondaが入れてあるため、そちらがデフォルトのpythonインタープリタになっています。もう一つのマシンには2015 Communityが入っていて、2013年に入れたおそらくpython.orgのpython27が入っていました。

しかしおかげで一つのマシン内に複数のpythonがインストールされている状態です。実際、Visual Studioの機能でｄ「python環境」というwindowがあり、そこでデバッグ/実行するときのpython環境を選べるようになっているくらいです。（いや、それCLIで実行するときはどうするんだよ、と突っ込みを入れたくなりますがそれも含めて考えてデバッグしろということでしょう。面倒くさい。）

この際、古いマシンの方のpythonをpython3にしようかと考えたんですが、ちょっとググってみたら、M$の推奨は悩んだらAnacondaが無難、Visual StudioのC++, C#と連携を考えるならIronPythonとのこと。調べると、IronPythonって、C#で実装されているとのこと。そのおかげで、Cythonもいけるらしい。しかしながら、python3がなくいまだに2.7というところが悲しいですが、ちょっと連携を試してみたいのでIronPythonを入れてみます。

Macもpythonは多数のバージョンがpyenvのおかげで入っていてひどいことになっています。python好きなんだけど、バージョン管理をなんとかして。（配布の時のハードルがかなり高いです）