1. 程式人生 > >Java UDP 重發機制

Java UDP 重發機制

一、重發訊息有兩個原因:

①接收方未收到,此時重發是應該的。②接收方收到訊息但是發回的應答包丟失了,此時重發訊息則重複了,所以在接收方還得新增一個機制:若收到的訊息與以前發過的訊息重複,則再次傳送應答包。在這些機制下,能夠初步的保證UDP傳輸的完整性。為了UDP包不在IP層上被分片,所以設計UDP包每個不得大於乙太網的MTU.採用相互握手重發

二、直接看程式碼

public void run() {

try{

String local_path = Environment.getExternalStorageDirectory().getPath() +"/gateway_update_file/"+ file_name;

File local_file =new File(local_path);

int size =new Long(local_file.length()).intValue();//檔案總的大小

System.out.println("檔案總的大小"+" = "+ size);

if(size ==0) {

//當前檔案為0,重新獲取檔案

//........

return;

}

//SEND_SIZE此變數為每包傳送的大小(跟接收返回的傳送包大小)

PACKETS= (size /SEND_SIZE) +1;//跟接收方定義的接收總的包數(即傳送多少包)

InetAddress inetAddress = InetAddress.getByName(GW_IP_ADDRESS);

if(socket==null) {

socket=newDatagramSocket(null);

socket.setReuseAddress(true);

socket.bind(newInetSocketAddress(Constants.UDP_PORT));

socket.setSoTimeout(3000);

}

inti;

int count =1;

FileInputStream fin =new FileInputStream(local_file);

byte[] bytes =new byte[SEND_SIZE];

while((i = fin.read(bytes,0,SEND_SIZE)) != -1) {//迴圈讀取檔案

byte[] send_byte = GatewayCmdData.FileDataToGatewayCmd(PACKETS, count, bytes);//此byte陣列為與接收方定義的資料結構體

DatagramPacket data =newDatagramPacket(send_byte, send_byte.length, inetAddress, Constants.UDP_PORT);

socket.send(data);

Log.i(TAG+"傳送的byte = ", Arrays.toString(bytes));

while(true) {

byte[] rec_byte =new byte[128];

DatagramPacket getack =newDatagramPacket(rec_byte, rec_byte.length);

socket.receive(getack);

if((int) MessageType.A.SEND_UPDATE_FILE_TO_GATEWAY.value() == rec_byte[11]) {過濾掉無用資料

ParseGatewayData.ParseUpdateCountData startUpdateData = new ParseGatewayData.ParseUpdateCountData();

startUpdateData.parseBytes(rec_byte);解析接收到的資料包含傳送的資料包次數(即第幾包)

if(count == startUpdateData.packet_count) {//如果返回的資料包次數與傳送包次數一致,則傳送下一包

if(startUpdateData.packet_count==PACKETS) {//最後確認包(即已經完成相關操作)

String crc32 = GatewayInfo.getInstance().getGatewayUpdateCRC32(context);

byte[] bt = GatewayCmdData.FinallyUpdateCmd(crc32);

DatagramPacket packet =newDatagramPacket(bt, bt.length, inetAddress, Constants.UDP_PORT);

socket.send(packet);

Log.i(TAG+" = ", TransformUtils.bytesToHexString(bt));

System.out.println("傳送最後一包= "+ TransformUtils.bytesToHexString(bt));

booleanisRun =true;

while(isRun){

socket.receive(getack);

if(rec_byte[32] ==0){

System.out.println("更新成功");

fin.close();

if(socket!=null){

socket.close();

最後關閉socket、檔案流

}

isRun =false;

DataSources.getInstance().GatewayUpdateResult(0);

}else{

System.out.println("更新失敗");

DataSources.getInstance().GatewayUpdateResult(1);

}

Log.i(TAG,"最後一包返回值= "+ Arrays.toString(rec_byte));

}

}

System.out.println("傳送下一包= "+ count);

count++;

break;

}

}else{

Thread.sleep(1000);

System.out.println("未接收到返回重新發送= "+ count);

socket.send(data);

}

}

}

}catch(Exception e) {

e.printStackTrace();

}finally{

System.out.println("finally = "+"UpdateHelper");

}

}


相關推薦

Java UDP 機制

一、重發訊息有兩個原因: ①接收方未收到,此時重發是應該的。②接收方收到訊息但是發回的應答包丟失了,此時重發訊息則重複了,所以在接收方還得新增一個機制:若收到的訊息與以前發過的訊息重複,則再次傳送應答包。在這些機制下,能夠初步的保證UDP傳輸的完整性。為了UDP包不在IP層

springboot+activemq中引入機制

簡介 一個 value nec ring cto 為我 body over 一、簡介 在使用activemq消息中間件進行消息隊列傳輸時,總會由於各種原因導致消息失敗。 一個經典的場景是一個生成者向Queue中發消息,裏面包含了一組郵件地址和郵件內容。而消費者從Queue中

ActiveMQ 機制與確認機制 實踐

方法 Coding ssa this 消息發送 als cer 出隊 引用 一、配置spring-activemq.xml 1 <?xml version="1.0" encoding="UTF-8"?> 2 <beans xmlns="http:/

activemq總結--機制

在activemq中存在訊息確認機制,即ACK機制,ACK (Acknowledgement),即確認字元,在資料通訊中,接收站發給傳送站的一種傳輸類控制字元。表示發來的資料已確認接收無誤。JMS API中約定了Client端可以使用四種ACK_MODE,在javax.jms.Session介面中:

使用performSelector設計最簡單的機制

重發機制 在對網路進行http請求或者物聯網產業中對閘道器進行不斷的傳送資料幀時,重發機制是一個必須存在的功能,來保證使用者操作的可靠性,app會不斷的重複傳送,直到資料成功傳送,並且接受到回覆幀。 performSelector performSelector: withObject:

簡訊機制

目前簡訊重發分別做在Modem和 App ,對應不同的情況。 Modem:      Modem的重發做在SMS-TL/ SMS-CM,針對傳送簡訊中的暫時性的錯誤。      其中涉及到很多底層技術細節,並且這些對於App層來說都是透明的。      但Modem端的處理可以保證會有1次重發,最長的等待時

Volley請求的機制

暮鼓集    行走集 原作於2017年01月02日 在傳送網路請求時,常常會遇到超時、迴應錯誤等情形,這時便需要考慮是否重發請求。Volley提供了一套機制,用於檢查問題及重發請求,這個機制的核心是RetryPolicy介面。 RetryP

Spring ActiveMQ 整合(二): 機制(訊息傳送失敗後的重新送)

       之前已經寫了一個spring   activemq整合的demo   ,今天繼續完善一下這個demo,讓功能更強大。        假如現在我手裡有一個很重要的訊息的,想要發給一個人,

nginx 機制導致的復扣款問題

str err 服務器 機制 停止 建立連接 head 後端服務 發送請求 問題: nginx 重發機制導制重復提交(客戶還款,被扣倆筆款,前端調用一次,後端執行2次) proxy_next_upstream 語法: proxy_next_upstream err

tcp機制,確認機制,視窗機制

1.累積確認    一般地講,如果傳送方發了包1,包2,包3,包4;接受方成功收到包1,包2,包3。那麼接受方可以發回一個確認包,序號為4。一個確認包確認了累積到某一序號的所有包。而不是對沒個序號都發確認包。2.重發    如果傳送端實體在合理的往返時延(RTT)內未收到確認,那麼對應的資料(假設丟失了)將會

使用SpringCloud Stream結合rabbitMQ實現訊息消費失敗機制

> 前言:實際專案中經常遇到訊息消費失敗了,要進行訊息的重發。比如支付訊息消費失敗後,要分不同時間段進行N次的訊息重發提醒。 # 本文模擬場景 1. 當金額少於100時,訊息消費成功 1. 當金額大於100,小於200時,會進行3次重發,第一次1秒;第二次2秒;第三次3秒。 1. 當金額大於200時

Java機制和底層實現原理

差距 32處理器 們的 trac 結點 exce jdk cep 定性   Java代碼在編譯後會變成Java字節碼,字節碼被類加載器加載到JVM裏,JVM執行字節碼轉化為匯編指令在CPU上執行。Java中的並發機制依賴於JVM的實現和CPU的指令。      Java語言

Java機制(4)--ThreadLocal線程本地變量(轉)

博客園 factor initial nec != highlight exc 不同的 htm 轉自:博客園-海子-http://www.cnblogs.com/dolphin0520/p/3920407.html Java並發編程:深入剖析ThreadL

ICE中地址對探測機制

if (c->state == PJ_ICE_SESS_CHECK_STATE_WAITING) { /* See if we shall nominate this check */ pj_bool_t nominate = (c->nominated

深入淺出之 TCP協議(三次握手與四次揮手、超時、流量控制、擁塞控制、與UDP區別)

TCP/IP 中有兩個具有代表性的傳輸層協議,分別是TCP、UDP。TCP提供可靠的通訊傳輸,而UDP則常被用於讓廣播和細節控制交給應用的通訊傳輸。 要知道TCP為了這簡單描述“可靠的通訊傳輸”背後所做的努力,你會深感佩服其強大性。TCP的特徵:序列化+確認應

jstorm kafkaspout未能實現fail機制功能

問題的發現是zookeeper kafka的消費offset很久沒有更新,通過打日誌發現 lastoffset其實是從傳送的儲存了所有傳送的offset的pendingOffsets(原始碼裡只是個treeset,阿里實現了ack,fail的非同步,居然沒用Concu

[JAVA]微信的請求解決辦法

最近給客戶做了個微信公眾號,其中在選單上配置的查詢功能需要訪問客戶系統介面獲取資料; 微信端的http請求在一定時間內(微信開發文件中寫的是5s,實際開發檢視報文是7s)無法得到返回的話會重發此請求。 微信的請求中會帶有一個code引數用於再次請求微信伺服器獲取微信使用者資

[瘋狂Java]UDP:接收送資料報、獲取接收到的資料報的相關資訊

1. Java的UDP模型:     1) DatagramSocket是UDP的socket,由於它只是個碼頭只能發貨和收貨,因此它就只有兩個方法,一個是send用來發送資料報,一個即使receive用來接收資料報;     2) 由於DatagramSocket只是個碼

[並編程的藝術] 02-Java機制的底層實現原理

bsp 代碼塊 none ace 多線程並發 clas strong 圖片 內存區域   Java代碼在編譯後會變成Java字節碼,字節碼被類加載起加載到JVM裏,JVM執行字節碼,最終需要轉化為匯編指令在CPU上執行, Java中所使用的並發機制依賴於JVM的實現和CPU

Java多線程機制

tro wid 機制 bsp 多核 idt http log 任務 Java 中的多線程簡介 1. 並發與並行的區別:   二者之間的區別在於,並發指的是一個處理器同時處理多個任務,並行指的是多個處理器或者是多核的處理器同時處理多個不同的任務. 2. 並發是邏輯上的同時發生