Q&A
回答ありがとうございます
makefile、調べてみました。つまり、そもそもsend/recvは古い関数なのでしょうか？
socket側がファイルを送るようなことを想定していて、それにあった関数を用意してくれているという認識であっていますでしょうか？
前提・実現したいこと
Pythonのソケット通信でファイルを送受信するソフトを作っています。
ファイルはpickleでバイナリデータにして送っています。
発生している問題・エラーメッセージ
同じファイル（バイナリデータ）なのに送受信が成功するときと失敗するときがあります
エラーメッセージは
pickle data was truncated
これになります。
送信側でのpickleデータをlenで数えたものと、受信側で最終的に受信できたデータの要素数を見ると
時々何故か途中までしか送信？受信？ができておらず、データが全然足りなくなってしまいます
この問題は、3回に一度ぐらいの確率でおき、コードを何も変えていないのにソフトを再起動すると治ることが多いです。
同じコード、同じデータでテストしているのに、なぜできるときとできないときがあるのかが本当に謎です
考えうる原因（例：Socketは不安定、そもそもそういう書き方は違うなど）があれば何でもいいので教えていただきたいです。
該当のソースコード
全文は長いので、受信側の受信部分のコードになります
Python
1rdata = sock.recv(4) 2datasize, = struct.unpack("l",rdata) 3rv = sock.recv(datasize) 4rv = pickle.loads(rv)
送信側は１、メインの送るバイナリデータ ２，１をlenで要素数を格納したデータ。の２つを送っています
１はpickleでバイナリ化したもので受信側のrvに入っていて、２はstructでpackしたデータになります
補足情報（FW/ツールのバージョンなど）
windows 10
VisualStudio Code
テストしたファイルタイプ txt pdf mp3 mp4
テストしたファイルサイズ 40バイトのものから~4MBぐらいのものまで、どれも成功するときとしないときがあります。
回答2件
0
例えば100バイトをsendしたとしても、recv(100)すると10バイトしか読まず、もう一度recvすると残りの90バイトを読むという事になるかもしれません。もしかすると2回でなく3回以上かかるかもしれません。ソケット通信というのはそういうものです。通信路の途中で、データの分割が発生する可能性があるからです。
なので、recvの返り値の長さを確認して、目的の長さが得られるまで繰り返します。
sendも同様で、100バイトsendしても40バイトしか送られないかもしれません。この場合はsendの返り値が40になるので、それを見て41バイト目から再度sendする必要があります。
投稿2021/11/28 17:23
総合スコア84505
0
recv で読み取る場合は、期待するサイズデータを受信するまで、
独自にバッファに溜める必要があります。
送信側でも問題になる場合があり、send で送っている場合は、
データの欠損が出る可能性があるので sendall を使う。
send/recv の代わりに makefile で作成したfile-likeオブジェクトに対して
writer/read で、ファイルで読み書きするような期待する挙動になるはずです。
高水準のライブラリ socketserver や asyncio でも、
より扱いやすいストリーム形式での読み書き方法を提供してます。
投稿2021/11/28 15:40
総合スコア8664
古いからという訳ではなく、状況による使い分けで
(意図の確認ですが、古くて廃止になった関数という訳ではありません。)
socket は低水準なインターフェースなので、
read/write の内部で recv/send が使われているといった感じです。
例えば、recv/send は、ライブラリやフレームワーク内部で使われる事はあります。
アプリケーション等では、直接扱うことは少なく、大抵はより高水準な扱いやすい方法を用います。
追記: ファイルを送るなら sendfile メソッドもあります
返信ありがとうございます
なるほど、大まかですが理解できました！わざわざ詳しくありがとうございます！
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2021/11/29 07:43
2021/11/29 10:53
2021/11/30 07:32