CN110533312A - 一种网约车方法及系统 - Google Patents

一种网约车方法及系统 Download PDF

Info

Publication number
CN110533312A
CN110533312A CN201910780577.1A CN201910780577A CN110533312A CN 110533312 A CN110533312 A CN 110533312A CN 201910780577 A CN201910780577 A CN 201910780577A CN 110533312 A CN110533312 A CN 110533312A
Authority
CN
China
Prior art keywords
client
worksheet processing
driver
processing message
sent
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201910780577.1A
Other languages
English (en)
Inventor
丁纯刚
杨金威
李翔
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Euler Information Services Co Ltd
Original Assignee
Euler Information Services Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Euler Information Services Co Ltd filed Critical Euler Information Services Co Ltd
Priority to CN201910780577.1A priority Critical patent/CN110533312A/zh
Publication of CN110533312A publication Critical patent/CN110533312A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06311—Scheduling, planning or task assignment for a person or group
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry

Landscapes

  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Tourism & Hospitality (AREA)
  • Development Economics (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Traffic Control Systems (AREA)

Abstract

本发明提供了一种网约车方法及系统，包括：接收乘客客户端发送的用车需求订单；根据用车需求订单，生成派单消息，并从多个司机客户端中确定与用车需求订单匹配的第一目标司机客户端，将所述派单消息通过长连接发送至第一目标司机客户端；若在第一时间阈值内接收到第一目标司机客户端发送的第一确认派单消息，则确定将派单消息发送成功；若在第一时间阈值内未接收到第一确认派单消息，则确定将派单消息发送失败。本发明中，服务器通过长连接发送派单消息和接收司机客户端返回的确认派单消息，来确认司机客户端是否接收到派单消息，从而避免了因长连接受较差的网络条件限制，导致司机客户端接收不到派单消息的情况，提高了网约车接单的可靠性。

Description

一种网约车方法及系统
技术领域
本发明涉及移动通讯领域，特别涉及一种网约车方法及系统。
背景技术
随着移动互联网的发展，智能交通系统开始普及，网约车是移动互联网辅助下的一种非常便利的出行方式，随着人们生活水平的提高，网约车得到了快速的发展。
现有的网约车服务架构包括乘客客户端、服务器和司机客户端，网约车在利用现有的网约车服务架构接收派单消息时，首先由司机客户端与服务器之间建立长连接，当服务器接收到乘客客户端发送的用车需求后，生成用车需求订单，然后从符合用车需求的司机客户端列表中选择一个目标司机客户端，通过目标司机客户端与服务器之间建立长连接，将派单消息发送给该目标司机客户端，目标司机客户端接收派单消息。
但是，在目前的方案中，由于司机在户外工作，手机网络经常处于不稳定状态，在一些情况下，长连接会受较差的网络条件限制，从而处于异常状态，导致服务器通过长连接发送派单消息后，司机客户端由于较差的网络条件限制，并未收到该派单消息，降低了网约车接单的可靠性。
发明内容
有鉴于此，本发明旨在提出一种网约车方法及系统，以解决现有技术中由于服务器与司机客户端之间的长连接受较差的网络条件限制，导致司机客户端接收不到派单消息的情况，提高网约车接单的可靠性。
为达到上述目的，本发明的技术方案是这样实现的：
一种网约车方法，所述方法包括：
接收乘客客户端发送的用车需求订单；
根据所述用车需求订单，从多个司机客户端中确定与所述用车需求订单匹配的第一目标司机客户端；
根据所述用车需求订单，生成派单消息，并将所述派单消息通过长连接发送至所述第一目标司机客户端；
若在第一时间阈值内接收到所述第一目标司机客户端发送的第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送成功；
若在所述第一时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送失败。
进一步的，在所述若在所述第一时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息时，则确定将所述派单消息针对所述第一目标司机客户端发送失败的步骤之后，所述方法还包括：
将所述派单消息通过长连接发送至第二目标司机客户端；所述第二目标司机客户端为所述多个司机客户端中与所述用车需求订单匹配的任意一个司机客户端，且所述第二目标司机客户端不同于所述第一目标司机客户端。
进一步的，在所述将所述派单消息通过长连接发送至第二目标司机客户端的步骤之后，所述方法还包括：
当在第二时间阈值内接收到所述第一目标司机客户端发送的所述第一确认派单消息，以及所述第二目标司机客户端发送的第二确认派单消息时，确定接收所述第一确认派单消息的第一时间，和接收所述第二确认派单消息的第二时间，所述第二时间阈值大于所述第一时间阈值；
若所述第一时间小于所述第二时间，则确定将所述派单消息针对所述第一目标司机客户端发送成功；
若所述第一时间大于所述第二时间，则确定将所述派单消息针对所述第二目标司机客户端发送成功。
进一步的，在所述将所述派单消息通过长连接发送至第二目标司机客户端的步骤之后，所述方法还包括：
当在所述第二时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，但接收到了所述第二目标司机客户端发送的所述第二确认派单消息时，则确定将所述派单消息针对所述第二目标司机客户端发送成功。
进一步的，在所述将所述派单消息通过长连接发送至第二目标司机客户端的步骤之后，所述方法还包括：
当在所述第二时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，以及所述第二目标司机客户端发送的所述第二确认派单消息时，将所述派单消息通过长连接发送至第三目标司机客户端；所述第三目标司机客户端为所述多个司机客户端中与所述用车需求订单匹配的任意一个司机客户端，且所述第三目标司机客户端不同于所述第一目标司机客户端和所述第二目标司机客户端。
进一步的，在所述若在所述第一时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息时，则确定将所述派单消息针对所述第一目标司机客户端发送失败的步骤之后，所述方法还包括：
接收所述乘客客户端发送的新的用车需求订单；
若所述第一目标司机客户端与所述新的用车需求订单匹配，则根据所述新的用车需求订单，生成新的派单消息，并将所述新的派单消息通过长连接发送至所述第一目标司机客户端。
进一步的，所述派单消息包括第一订单号；所述第一确认派单消息包括第二订单号；在所述若在所述第一时间阈值内接收到所述第一目标司机客户端发送的第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送成功的步骤之后，所述方法还包括：
若所述第一订单号和所述第二订单号之间为非正则匹配，则确定所述第一目标司机客户端接收到的所述派单消息与所述用车需求订单不匹配；
若所述第一订单号和第二订单号之间为正则匹配，则确定所述第一目标司机客户端接收到的所述派单消息与所述用车需求订单匹配。
进一步的，在所述根据所述用车需求订单，生成派单消息之后，所述方法还包括：
按照预设时间周期，将所述派单消息通过长连接发送至所述第一目标司机客户端，直至接收到所述第一目标司机客户端返回的第一确认派单消息时停止；
在接收到所述第一目标司机客户端返回的所述第一确认派单消息时，确定所述派单消息针对所述第一目标司机客户端发送成功。
进一步的，所述长连接为套接字长连接或传输控制协议长连接。
一种服务器，所述服务器包括：
第一接收模块：用于接收乘客客户端发送的用车需求订单；
第一确认模块：用于根据所述用车需求订单，从多个司机客户端中确定与所述用车需求订单匹配的第一目标司机客户端；
第一发送模块：用于根据所述用车需求订单，生成派单消息，并将所述派单消息通过长连接发送至所述第一目标司机客户端；
第二确认模块：用于若在第一时间阈值内接收到所述第一目标司机客户端发送的第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送成功；
第三确认模块：用于若在所述第一时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送失败。
进一步的，所述服务器还包括：
第二发送模块：用于将所述派单消息通过长连接发送至第二目标司机客户端；所述第二目标司机客户端为所述多个司机客户端中与所述用车需求订单匹配的任意一个司机客户端，且所述第二目标司机客户端不同于所述第一目标司机客户端。
进一步的，所述服务器还包括：
第四确认模块：用于在第二时间阈值内接收到所述第一目标司机客户端发送的所述第一确认派单消息，以及所述第二目标司机客户端发送的第二确认派单消息时，确定接收所述第一确认派单消息的第一时间，和接收所述第二确认派单消息的第二时间，所述第二时间阈值大于所述第一时间阈值；
第五确认模块：用于若所述第一时间小于所述第二时间，则确定将所述派单消息针对所述第一目标司机客户端发送成功；
第六确认模块：用于若所述第一时间大于所述第二时间，则确定将所述派单消息针对所述第二目标司机客户端发送成功。
进一步的，所述服务器还包括：
第七确认模块：用于在所述第二时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，但接收到了所述第二目标司机客户端发送的所述第二确认派单消息时，则确定将所述派单消息针对所述第二目标司机客户端发送成功。
进一步的，所述服务器还包括：
第三发送模块：用于在所述第二时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，以及所述第二目标司机客户端发送的所述第二确认派单消息时，将所述派单消息通过长连接发送至第三目标司机客户端；所述第三目标司机客户端为所述多个司机客户端中与所述用车需求订单匹配的任意一个司机客户端，且所述第三目标司机客户端不同于所述第一目标司机客户端和所述第二目标司机客户端。
进一步的，所述服务器还包括：
第二接收模块：用于接收所述乘客客户端发送的新的用车需求订单；
第四发送模块：用于若所述第一目标司机客户端与所述新的用车需求订单匹配，则根据所述新的用车需求订单，生成新的派单消息，并将所述新的派单消息通过长连接发送至所述第一目标司机客户端。
进一步的，所述派单消息包括第一订单号；所述确认派单消息包括第二订单号，所述服务器还包括：
第一匹配确认模块：用于若所述第一订单号和所述第二订单号之间为非正则匹配，确定所述第一目标司机客户端接收到的所述派单消息与所述用车需求订单不匹配；
第二匹配确认模块：用于若所述第一订单号和第二订单号之间为正则匹配，确定所述第一目标司机客户端接收到的所述派单消息与所述用车需求订单匹配。
进一步的，所述服务器还包括：
第五发送模块：用于按照预设时间周期，将所述派单消息通过长连接发送至所述第一目标司机客户端，直至接收到所述第一目标司机客户端返回的第一确认派单消息时停止；
第八确认模块：用于在接收到所述第一目标司机客户端返回的所述第一确认派单消息时，确定所述派单消息针对所述第一目标司机客户端发送成功。
进一步的，所述长连接为套接字长连接或传输控制协议长连接。
一种网约车系统，所述系统包括乘客客户端、司机客户端和服务器。
其中，所述乘客客户端用于发送用车需求订单至服务器；
所述服务器用于接收所述乘客客户端发送的所述用车需求订单，并根据所述用车需求订单，从多个所述司机客户端中确定与所述用车需求订单匹配的第一目标司机客户端；以及根据所述用车需求订单，生成派单消息，并将所述派单消息通过长连接发送至所述第一目标司机客户端；若在第一时间阈值内接收到所述第一目标司机客户端发送的第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送成功；若在所述第一时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送失败；
所述司机客户端用于接收所述服务器发送的所述派单消息，若接收到所述派单消息，则发送所述第一确认派单消息至所述服务器。
相对于现有技术，本发明所述的一种网约车方法及系统具有以下优势：
本发明实施例提供的一种网约车方法及系统，包括：接收乘客客户端发送的用车需求订单；根据用车需求订单，从多个司机客户端中确定与用车需求订单匹配的第一目标司机客户端；根据用车需求订单，生成派单消息，并将派单消息通过长连接发送至第一目标司机客户端；若在第一时间阈值内接收到第一目标司机客户端发送的第一确认派单消息，则确定将派单消息针对第一目标司机客户端发送成功；若在第一时间阈值内未接收到第一目标司机客户端发送的第一确认派单消息，则确定将派单消息针对第一目标司机客户端发送失败。本发明中，服务器通过长连接发送派单消息和接收司机客户端返回的确认派单消息，来确认司机客户端是否接收到派单消息，从而避免了长连接受较差的网络条件限制，导致司机客户端接收不到派单消息的情况，提高了网约车接单的可靠性。
附图说明
构成本发明的一部分的附图用来提供对本发明的进一步理解，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1为本发明实施例所述的一种网约车方法的步骤流程图；
图2为本发明实施例所述的长连接建立过程示意图；
图3为本发明实施例所述的另一种网约车方法的步骤流程图；
图4为本发明实施例所述的另一种网约车方法的步骤流程图；
图5为本发明实施例所述的另一种网约车方法的交互步骤流程图；
图6为本发明实施例所述的一种服务器的结构框图；
图7为本发明实施例所述的一种网约车系统的结构框图。
具体实施方式
需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。
下面将参考附图并结合实施例来详细说明本发明。
参照图1，示出了本发明实施例所述的一种网约车方法的步骤流程图。
步骤101，接收乘客客户端发送的用车需求订单。
在本发明实施例中，当乘客有用车需求后，通过乘客客户端生成用车需求订单，并通过乘客客户端将用车需求订单发送至服务器，服务器接收乘客客户端发送的用车需求订单。
优选地，为成功匹配到符合乘客用车需求的目标司机客户端，所述用车需求订单中可以包含乘客的用车要求。所述用车要求可以包括乘客期望呼叫的车辆的类型、档次、是否呼叫拼车等。例如，乘客可以根据需求，通过乘客客户端选择期望呼叫的车辆的类型为两厢轿车、三厢轿车、城市运动型实用汽车、越野运动型实用汽车、面包车型多用途汽车、家庭商旅型多用途汽车等，选择期望呼叫的车辆的档次为低档车、中档车、高档车、豪华车等，选择与他人拼车或不与他人拼车。
此外，用车需求订单中还应包括乘客的上车地点和目的地，乘客需要在乘客客户端中输入或在乘客客户端中预置的地图上选择上车地点和目的地，以便服务器确定接送乘客的司机对应的司机客户端。
步骤102，根据所述用车需求订单，从多个司机客户端中确定与所述用车需求订单匹配的第一目标司机客户端。
在该步骤中，司机可以通过司机客户端向服务器发送注册请求，从而实现注册操作，在注册操作完成之后，服务器中可以存储有司机客户端和对应司机的相关信息，具体的，所述司机客户端和对应司机的相关信息可以包括：车辆的类型、档次、车辆颜色、车牌号、司机姓名、司机联系方式等。
进一步的，在服务器接收到所述用车需求订单之后，可以在注册过的司机客户端中，选择符合用车需求订单的司机客户端，生成司机客户端列表，再根据用车需求订单中乘客的上车地点和司机客户端的当前位置，从符合乘客用车需求的司机客户端列表中选出一个司机客户端，确定该司机客户端为与用车需求订单匹配的第一目标司机客户端。
可选的，为保证乘客在更短的时间内呼叫到网约车，服务器确定的第一目标司机客户端可以是距离乘客客户端最近的。优选地，服务器可以结合路况信息，根据乘客的上车地点和司机客户端的当前位置，计算出从司机客户端的当前位置行驶到乘客的上车地点的过程中，用时最短的司机客户端，服务器确定该司机客户端为第一目标司机客户端。
优选地，所述司机客户端的当前位置可以利用全球定位系统(GlobalPositioning System,GPS)或者基站定位技术确定。
步骤103，根据所述用车需求订单，生成派单消息，并将所述派单消息通过长连接发送至所述第一目标司机客户端。
在该步骤中，第一目标司机客户端与服务器之间可以建立长连接，然后服务器可以将根据用车需求订单生成的派单消息通过所述长连接发送至第一目标司机客户端。
在本发明实施例中，服务器根据乘客客户端发送的用车需求订单，生成派单消息，优选的，所述派单消息可以包括乘客人数、乘客身份信息、乘客的上车地点、用车需求订单生成的时间、派单消息的订单号等，如所述派单消息可以为：“乘客××于××时间呼叫网约车，乘车人数为×人，上车地点为××，该派单消息的订单号为××××××”。
具体的，所述长连接，是指在一个链接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。实时通讯可以通过短连接和长连接的方式实现，短连接是每次请求都建立链接，交互完之后关闭链接，而长连接是初始建立链接并保持，后续所有请求都走该通道。短连接构建相对简单，信息传输相对可靠，但每次建立链接耗时多、性能低，并且服务端无法主动推送消息给客户端。而长连接，构建相对复杂，信息传输的可靠性需要有一套机制来保障。
进一步的，建立长连接需要客户端与服务器经过三次握手才能建立，建立长连接的过程如图2所示：
第一次握手：客户端将标志位同步序列编号(Synchronize Sequence Numbers，SYN)置为1，随机产生一个值seq＝J，并将该数据包发送给服务器，客户端进入SYN_SENT状态，等待服务器确认。
第二次握手：服务器接收到数据包之后，由标志位SYN＝1知道客户端请求建立连接，服务器将标志位SYN和ACK都置为1，ack＝J+1，随机产生一个值seq＝K，并将该数据包发送给客户端以确认连接请求，服务器进入SYN_RCVD状态。
第三次握手：客户端接收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack＝K+1，并将该数据包发送给服务器，服务器检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，客户端和服务器进入ESTABLISHED状态，完成三次握手，随后客户端与服务器之间可以开始传输数据。
进一步的，服务器可以通过与客户端之间建立的长连接，将派单消息发送至第一目标司机客户端。
步骤104，若在第一时间阈值内接收到所述第一目标司机客户端发送的第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送成功。
在步骤103中，服务器通过长连接，将派单消息发送给第一目标司机客户端，第一目标司机客户端接收该派单消息，生成第一确认派单消息，并将所述第一确认派单消息发送至服务器。第一目标司机客户端生成并发送所述第一确认派单消息的过程，是针对派单消息进行的确认操作，所述第一确认派单消息可以为：“第一目标司机客户端于××时间接收到订单号为××××××的派单消息。”
在本发明实施例中，服务器与司机客户端之间时通过长连接进行数据的接收和发送，理论上说，该长连接是一直保持连接状态的，但在实际情况中，长连接进行一次数据交互后，很长一段时间内无数据交互时，司机客户端可能意外断电、死机、崩溃、重启，或者网络无故断开，导致长连接不可用，但这时长连接并未来得及正常断开，服务器并不知道司机客户端的情况，会一直维持这个长连接，造成系统资源的消耗和浪费，并且可能导致在一个无效的数据链路层面发送派单消息，导致派单消息发送失败。
在步骤104中，通过判断服务器在第一时间阈值内是否接收到第一目标司机客户端返回的第一确认派单消息，来确定派单消息针对第一目标司机客户端是否发送成功。
具体的，若在第一时间阈值内接收到所述第一目标司机客户端发送的第一确认派单消息，则可以确定所述派单消息针对所述第一目标司机客户端发送成功。
优选地，所述第一时间阈值可以是一个固定的时间，比如：20秒，30秒。在第一时间阈值内，所述第一目标司机客户端处于锁定状态，此时第一目标司机客户端不能接收服务器发送的其他派单消息。
步骤105，若在所述第一时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送失败。
在步骤103中，服务器通过长连接，派单消息发送给第一目标司机客户端，第一目标司机客户端接收该派单消息，并生成第一确认派单消息，并将所述第一确认派单消息发送至服务器。第一目标司机客户端生成并发送所述第一确认派单消息的过程，是针对派单消息进行的确认操作，所述第一确认派单消息可以为：“第一目标司机客户端于××时间接收到订单号为××××××的派单消息。”
在该步骤中，若在第一时间阈值内未接收到所述第一目标司机客户端发送的第一确认派单消息，则可以确定所述派单消息针对所述第一目标司机客户端发送失败。
优选的，所述第一时间阈值可以是一个固定的时间，比如：20秒，30秒。在第一时间阈值内，所述第一目标司机客户端处于锁定状态，此时第一目标司机客户端不能接收服务器发送的其他派单消息。但当时间超出了第一时间阈值，而且未接收到第一目标司机客户端发送的第一确认派单消息时，确定所述派单消息针对所述第一目标司机客户端发送失败，将处于锁定状态的第一目标司机客户端进行解锁，使其可以接接收服务器发送的新的派单消息。从而避免在长连接不可用时，服务器发送派单消息后，长时间无效锁定第一目标司机客户端，导致其他用车需求订单没有足够的司机客户端进行匹配。
综上所述，本发明实施例提供的一种网约车方法，包括：接收乘客客户端发送的用车需求订单；根据用车需求订单，从多个司机客户端中确定与用车需求订单匹配的第一目标司机客户端；根据用车需求订单，生成派单消息，并将派单消息通过长连接发送至第一目标司机客户端；若在第一时间阈值内接收到第一目标司机客户端发送的第一确认派单消息，则确定将派单消息针对第一目标司机客户端发送成功；若在第一时间阈值内未接收到第一目标司机客户端发送的第一确认派单消息，则确定将派单消息针对第一目标司机客户端发送失败。本发明实施例中，服务器通过长连接发送派单消息和接收司机客户端返回的确认派单消息，来确认司机客户端是否接收到派单消息，从而避免了长连接受较差的网络条件限制，导致司机客户端接收不到派单消息的情况，提高了网约车接单的可靠性。
参照图3，示出了本发明实施例所述的另一种网约车方法的步骤流程图。
步骤201，接收乘客客户端发送的用车需求订单。
该步骤具体可以参照上述步骤101，此处不再赘述。
步骤202，根据所述用车需求订单，从多个司机客户端中确定与所述用车需求订单匹配的第一目标司机客户端。
该步骤具体可以参照上述步骤102，此处不再赘述。
步骤203，根据所述用车需求订单，生成派单消息，并将所述派单消息通过长连接发送至所述第一目标司机客户端。
该步骤具体可以参照上述步骤103，此处不再赘述。
步骤204，判断在第一时间阈值内是否接收到第一目标司机客户端发送的第一确认派单消息。
在该步骤中，若判断服务器在第一时间阈值内接收到所述第一目标司机客户端发送的第一确认派单消息，执行步骤205，若判断服务器在第一时间阈值内未接收到所述第一目标司机客户端发送的第一确认派单消息，执行步骤206。
具体的，服务器通过长连接，将派单消息发送给第一目标司机客户端，第一目标司机客户端接收该派单消息，并生成第一确认派单消息，并将所述第一确认派单消息发送至服务器。第一目标司机客户端生成并发送所述第一确认派单消息的过程，是针对派单消息进行的确认操作，所述第一确认派单消息可以为：“第一目标司机客户端于××时间接收到订单号为××××××的派单消息。”
优选的，所述第一时间阈值可以是一个固定的时间，比如：20秒，30秒。
步骤205，确定将所述派单消息针对所述第一目标司机客户端发送成功。
在该步骤中，确定服务器在第一时间阈值内接收到了第一目标司机客户端发送的第一确认派单消息，则说明服务器发送派单消息时长连接是可用的，所述派单消息通过长连接成功发送给了第一目标司机客户端。
在本发明实施例中，若步骤205在步骤210之后执行，则说明服务器接收所述第一确认派单消息的第一时间小于接收所述第二确认派单消息的第二时间，即说明第一目标司机客户端相较于第二目标司机客户端，较早的对服务器发送的派单消息进行了回馈，则确定将所述派单消息针对所述第一目标司机客户端发送成功。
进一步的，可以在第一确认派单消息包含的订单号与所述派单消息包含的订单号为正则匹配的情况下，确定第一目标司机客户端接收到的派单消息与乘客客户端生成的用车需求订单相匹配，乘客通过网约车系统成功呼叫第一目标司机客户端对应的网约车，第一目标司机客户端通知对应的司机处理派单任务。同时，服务器可以向第二目标司机客户端发送派单失败消息，通知第二目标司机客户端该用车需求订单已经与其他司机客户端相匹配。
步骤206，确定将所述派单消息针对所述第一目标司机客户端发送失败。
在该步骤中，确定服务器在第一时间阈值内未接收到第一目标司机客户端发送的第一确认派单消息，其原因可能是服务器与第一目标司机客户端之间的长连接在发送派单消息时处于不可用的状态，导致所述派单消息未能通过长连接成功发送；或者是服务器与第一目标司机客户端之间的长连接在接收第一确认派单消息时处于不可用的状态，导致所述第一确认派单消息未能通过长连接成功发送；也可能是第一目标司机客户端通过长连接接收到了派单消息，但是并未在第一时间阈值内返回第一确认派单消息，比如第一目标司机客户端对应的司机此时处于休息状态，未能在第一时间阈值内通过第一目标司机客户端返回第一确认派单消息，此时也可以认为所述派单消息针对第一目标司机客户端发送失败，将处于锁定状态的第一目标司机客户端进行解锁操作，避免长时间无效锁定第一目标司机客户端，导致其他用车需求订单没有足够的司机客户端进行匹配。
步骤207，将所述派单消息通过长连接发送至第二目标司机客户端；所述第二目标司机客户端为所述多个司机客户端中与所述用车需求订单匹配的任意一个司机客户端，且所述第二目标司机客户端不同于所述第一目标司机客户端。
在该步骤中，当确认派单消息针对第一目标司机客户端发送失败后，再次根据用车需求订单，从除第一目标司机客户端之外的多个司机客户端中，确定与用车需求订单匹配的第二目标司机客户端，即所述第二目标司机客户端与所述第一目标司机客户端不会是同一个司机客户端，因为在大多数情况下，服务器与第一目标司机客户端之间的长连接在较短时间内恢复可用的可能性较小，以及在较短时间内第一目标司机客户端对应的司机快速的返回第一确认派单消息的可能性较小，因此，在确定第二目标司机客户端时，排除第一目标司机客户端。
具体的，根据用车需求订单，从除第一目标司机客户端之外的多个司机客户端中，确定与用车需求订单匹配的第二目标司机客户端，可以参照上述步骤102，此处不再赘述。
可选的，在步骤207之后，可以执行：
步骤208，当在第二时间阈值内接收到所述第一目标司机客户端发送的所述第一确认派单消息，以及所述第二目标司机客户端发送的第二确认派单消息时，确定接收所述第一确认派单消息的第一时间，和接收所述第二确认派单消息的第二时间，所述第二时间阈值大于所述第一时间阈值。
在该步骤中，在确定第二目标司机客户端，并将派单消息通过长连接发送至第二目标司机客户端之后，若在第二时间阈值内，既接收到所述第一目标司机客户端发送的所述第一确认派单消息，同时又接收到第二目标司机客户端发送的第二确认派单消息时，确认接收所述第一确认派单消息的第一时间，和接收所述第二确认派单消息的第二时间。所述第二时间阈值大于所述第一时间阈值，优选的，所述第二时间阈值可以是一个固定的时间，比如：40秒，60秒。
具体的，若第一目标司机客户端在第一时间阈值内由于对应的司机此时处于休息状态等原因，未能在第一时间阈值内通过第一目标司机客户端返回第一确认派单消息，但在第二时间阈值内，通过第一目标司机客户端返回了第一确认派单消息，同时，第二目标司机客户端也返回了第二确认派单消息，则会使得服务器在第二时间阈值内，既接收到所述第一目标司机客户端发送的所述第一确认派单消息，同时又接收到第二目标司机客户端发送的第二确认派单消息。
在本发明实施例中，服务器通过长连接，将派单消息发送给第二目标司机客户端，第二目标司机客户端接收该派单消息，生成第二确认派单消息，并将所述第二确认派单消息发送至服务器。第二目标司机客户端生成并发送所述第二确认派单消息的过程，是针对派单消息进行的确认操作，所述第二确认派单消息可以为：“第二目标司机客户端于××时间接收到订单号为××××××的派单消息。”
步骤211，判断第一时间是否小于第二时间。
在步骤210中，服务器既接收到了所述第一目标司机客户端发送的所述第一确认派单消息，同时又接收到了第二目标司机客户端发送的第二确认派单消息，在确定了接收所述第一确认派单消息的第一时间和接收所述第二确认派单消息的第二时间之后，对所述第一时间和第二时间进行比较，判断第一时间是否小于第二时间，若判断第一时间小于第二时间，则执行步骤205，若判断第一时间大于第二时间，则执行步骤212，若判断第一时间等于第二时间，可随机选择执行步骤205或步骤212。
步骤212，确定将派单消息针对第二目标司机客户端发送成功。
在该步骤中，服务器接收所述第一确认派单消息的第一时间大于接收所述第二确认派单消息的第二时间，即说明第二目标司机客户端相较于第一目标司机客户端，较早的对服务器发送的派单消息进行了回馈，则确定将所述派单消息针对所述第二目标司机客户端发送成功。
进一步的，可以在第二确认派单消息包含的订单号与所述派单消息包含的订单号为正则匹配的情况下，确定第二目标司机客户端接收到的派单消息与乘客客户端生成的用车需求订单相匹配，乘客通过网约车系统成功呼叫第二目标司机客户端对应的网约车，第二目标司机客户端通知对应的司机处理派单任务。同时，服务器可以向第一目标司机客户端发送派单失败消息，通知第一目标司机客户端该用车需求订单已经与其他司机客户端相匹配。
可选的，在步骤207之后，还可以执行：
步骤209，当在所述第二时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，但接收到了所述第二目标司机客户端发送的所述第二确认派单消息时，则确定将所述派单消息针对所述第二目标司机客户端发送成功。
在该步骤中，在确定第二目标司机客户端，并将派单消息通过长连接发送至第二目标司机客户端之后，若在第二时间阈值内，未接收到所述第一目标司机客户端发送的所述第一确认派单消息，但接收到了所述第二目标司机客户端发送的所述第二确认派单消息时，就可以确定将派单消息针对第二目标司机客户端发送成功。
优选的，所述第二时间阈值可以是一个固定的时间，比如：40秒，60秒。
在本发明实施例中，服务器通过长连接，将派单消息发送给第二目标司机客户端，第二目标司机客户端接收该派单消息，生成第二确认派单消息，并将所述第二确认派单消息发送至服务器。第二目标司机客户端生成并发送所述第二确认派单消息的过程，是针对派单消息进行的确认操作，所述第二确认派单消息可以为：“第二目标司机客户端于××时间接收到订单号为××××××的派单消息。”
可选的，在步骤207之后，还可以执行：
步骤210，当在所述第二时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，以及所述第二目标司机客户端发送的所述第二确认派单消息时，将所述派单消息通过长连接发送至第三目标司机客户端；所述第三目标司机客户端为所述多个司机客户端中与所述用车需求订单匹配的任意一个司机客户端，且所述第三目标司机客户端不同于所述第一目标司机客户端和所述第二目标司机客户端。
在该步骤中，当在第二时间阈值内既未接收到第一目标司机客户端发送的第一确认派单消息，也未接收到第二目标司机客户端发送的所述第二确认派单消息时，则可以认为派单消息在第二时间阈值内针对第一目标司机客户端和第二目标司机客户端均发送失败。在这种情况下，服务器将再次根据用车需求订单，从除第二目标司机客户端之外的多个司机客户端中，确定与用车需求订单匹配的第三目标司机客户端，即所述第三目标司机客户端与所述第二目标司机客户端不会是同一个司机客户端，但所述第三目标司机客户端与所述第一目标司机客户端可以是同一个司机客户端，因为此时已经距离服务器向第一目标司机客户端发送派单消息有较长的时间间隔，此时服务器与第一目标司机客户端之间的长连接可能已经恢复可用，或者第一目标司机客户端对应的司机此时处于可以快速确认派单消息的状态下。
具体的，根据用车需求订单，从除第二目标司机客户端之外的多个司机客户端中，确定与用车需求订单匹配的第三目标司机客户端，可以参照上述步骤102，此处不再赘述。
可选的，在步骤206之后，还可以执行：
步骤213，接收所述乘客客户端发送的新的用车需求订单。
在该步骤中，在确定将派单消息针对第一目标司机客户端发送失败的情况下，可以接收乘客客户端发送的新的用车需求订单。
该步骤具体可以参照上述步骤101，此处不再赘述。
步骤214，若所述第一目标司机客户端与所述新的用车需求订单匹配，则根据所述新的用车需求订单，生成新的派单消息，并将所述新的派单消息通过长连接发送至所述第一目标司机客户端。
在该步骤中，若服务器确定第一目标司机客户端与所述新的用车需求订单匹配，则可以将根据新的用车需求订单生成的新的派单消息，通过长连接发送至第一目标司机客户端。
可选的，在步骤205之后，可以执行：
步骤215，所述派单消息包括第一订单号；所述第一确认派单消息包括第二订单号；判断第一订单号和第二订单号之间是否为正则匹配。
在该步骤中，若判断所述第一订单号和所述第二订单号之间为正则匹配，执行步骤216，若所述第一订单号和所述第二订单号之间为非正则匹配，执行步骤217。
具体的，在步骤203中生成的派单消息中，包含第一订单号，在步骤204中生成的第一确认派单消息中，包含第二订单号。将所述第一订单号与所述第二订单号进行比较，判断两者是否为正则匹配。
步骤216，确定所述第一目标司机客户端接收到的所述派单消息与所述用车需求订单匹配。
在该步骤中，派单消息的第一订单号与第一确认派单消息的第二订单号为正则匹配的条件下，可以确定第一目标司机客户端返回的第一确认派单消息与乘客客户端发送的派单消息是相互匹配的，即第一目标司机客户端接收到的派单消息与乘客在产生用车需求后，通过乘客客户端生成并发送的用车需求订单相匹配。
步骤217，确定所述第一目标司机客户端接收到的所述派单消息与所述用车需求订单不匹配。
在该步骤中，派单消息的第一订单号与第一确认派单消息的第二订单号为非正则匹配的条件下，可以确定第一目标司机客户端返回的第一确认派单消息与乘客客户端发送的派单消息是不匹配的，即第一目标司机客户端接收到的派单消息与乘客在产生用车需求后，通过乘客客户端生成并发送的用车需求订单不匹配。
在另一种情况下，判断所述派单消息与用车需求订单是否匹配还可以通过以下方法来实现：判断第一订单号和第二订单号之间是否为正则匹配、判断用车需求订单是否为待匹配，以及判断第一目标司机客户端是否为待匹配三种判断条件共同进行判断。
所述用车需求订单的状态有匹配成功、待匹配和已撤回三种状态，若所述用车需求订单处于匹配成功状态，说明服务器已经为该用车需求订单匹配了对应的司机客户端，并将该用车需求订单发送给了对应的司机客户端；若所述用车需求订单处于已撤回状态，说明乘客已经通过乘客客户端将所述用车需求订单撤回，此时乘客没有用车需求；若所述用车需求订单处于待匹配状态，则说明该用车需求订单仍未匹配成功司机客户端，而且乘客此时仍有用车需求。
所述第一目标司机客户端的匹配状态有锁定、未锁定和已匹配三种状态，若所述第一目标司机客户端处于锁定或未锁定状态，说明第一目标司机客户端此时没有接收用车需求订单，处于可以接收用车需求订单的条件下；若所述第一目标司机客户端处于已匹配状态，说明第一目标司机客户端此时已经接收了其他用车需求订单，需要根据用车需求订单前往对应乘客的上车位置接乘客，不能再处理用车需求订单。
具体的，在上述三个判断结果均为是时，即判断第一订单号和第二订单号之间为正则匹配、用车需求订单为待匹配、第一目标司机客户端为待匹配的情况下，才能确定所述派单消息与所述用车需求订单相匹配。若上述三个判断结果任一为否时，即判断第一订单号和第二订单号之间为非正则匹配，或用车需求订单不是待匹配，或第一目标司机客户端不是待匹配的情况下，确定所述派单消息与所述用车需求订单不匹配。
综上所述，本发明实施例提供的一种网约车方法，包括：接收乘客客户端发送的用车需求订单；根据用车需求订单，从多个司机客户端中确定与用车需求订单匹配的第一目标司机客户端；根据用车需求订单，生成派单消息，并将派单消息通过长连接发送至第一目标司机客户端；若在第一时间阈值内接收到第一目标司机客户端发送的第一确认派单消息，则确定将派单消息针对第一目标司机客户端发送成功；若在第一时间阈值内未接收到第一目标司机客户端发送的第一确认派单消息，则确定将派单消息针对第一目标司机客户端发送失败。本发明实施例中，当确定派单消息针对第一目标司机客户端发送失败的情况下，在第二时间阈值内，将派单消息通过长连接发送至第二目标司机客户端，以确保在第一目标司机客户端接收派单消息失败时，在较短的时间内可以重新确定符合用车需求的第二目标司机客户端，减少乘客呼叫网约车的时间，并提高乘客成功呼叫网约车的几率。
进一步的，若在第二时间阈值内接收到第一确认派单消息和第二派单消息时，确认较早接收到的确认派单消息，并确定该确认派单消息对应的目标司机客户端成功接收派单消息，进一步减少乘客呼叫网约车的时间，提高乘客呼叫网约车的用户体验度。
参照图4，示出了本发明实施例所述的另一种网约车方法的步骤交流图。
步骤301，接收乘客客户端发送的用车需求订单。
该步骤具体可以参照上述步骤101，此处不再赘述。
步骤302，根据所述用车需求订单，从多个司机客户端中确定与所述用车需求订单匹配的第一目标司机客户端。
该步骤具体可以参照上述步骤102，此处不再赘述。
步骤303，根据所述用车需求订单，生成派单消息。
该步骤具体可以参照上述步骤103，此处不再赘述。
步骤304，按照预设时间周期，将所述派单消息通过长连接发送至所述第一目标司机客户端，直至接收到所述第一目标司机客户端返回的第一确认派单消息时停止。
在该步骤中，服务器根据用车需求订单生成派单消息，确定第一目标司机客户端之后，按照预设时间周期，将派单消息通过长连接持续不间断的发送至第一目标司机客户端，直至接收到所述第一目标司机客户端返回的第一确认派单消息时，停止向第一目标司机客户端发送派单消息。
优选地，所述预设时间周期可以服务器根据实际情况设定的一个固定的时间，可以为1分钟、2分钟。
步骤305，在接收到所述第一目标司机客户端返回的所述第一确认派单消息时，确定所述派单消息针对所述第一目标司机客户端发送成功。
在该步骤中，确定服务器接收到了第一目标司机客户端发送的第一确认派单消息，则说明服务器发送派单消息时长连接是可用的，所述派单消息通过长连接成功发送给了第一目标司机客户端。
综上所述，本发明实施例提供的一种网约车方法，包括：接收乘客客户端发送的用车需求订单；根据用车需求订单，从多个司机客户端中确定与用车需求订单匹配的第一目标司机客户端；根据用车需求订单，生成派单消息；按照预设时间周期，将所述派单消息通过长连接发送至所述第一目标司机客户端，直至接收到所述第一目标司机客户端返回的第一确认派单消息时停止；在接收到所述第一目标司机客户端返回的所述第一确认派单消息时，确定所述派单消息针对所述第一目标司机客户端发送成功。本发明实施例中，服务器按照预设周期发送派单消息至第一目标司机客户端，直至接收到第一确认派单消息，从而可以避免服务器向第一目标司机客户端发送派单消息时，由于网络条件较差等原因导致服务器与第一目标司机客户端之间的长连接不可用，使得并未将派单消息成功发送至第一目标司机客户端的情况，提高了网约车接单的可靠性。
参照图5，示出了本发明实施例所述的另一种网约车方法的交互步骤流程图。
步骤401，第一目标司机客户端与服务器建立长连接。
在该步骤中，第一目标司机客户端与服务器通过三次握手建立长连接，所述长连接建立之后，可以持久保持连接，并可以进行双向数据传输，所述长连接建立的具体步骤可以参照上述步骤103，此处不再赘述。
步骤402，乘客客户端接收用车需求。
在该步骤中，乘客在有呼叫网约车的需求时，向乘客客户端输入用车需求，乘客客户端接收用车需求。
步骤403，乘客客户端生成用车需求订单。
乘客客户端根据接收到的乘客的用车需求，生成用车需求订单。
优选地，为成功匹配到符合乘客用车需求的目标司机客户端，所述用车需求订单中可以包含乘客的用车要求。所述用车要求可以包括乘客期望呼叫的车辆的类型、档次、是否呼叫拼车等。例如，乘客可以根据需求，通过乘客客户端选择期望呼叫的车辆的类型为两厢轿车、三厢轿车、城市运动型实用汽车、越野运动型实用汽车、面包车型多用途汽车、家庭商旅型多用途汽车等，选择期望呼叫的车辆的档次为低档车、中档车、高档车、豪华车等，选择与他人拼车或不与他人拼车。
此外，用车需求订单中还应包括乘客的上车地点和目的地，乘客需要在乘客客户端中输入或在乘客客户端中预置的地图上选择上车地点和目的地，以便服务器确定接送乘客的司机对应的司机客户端。
步骤404，乘客客户端将所述用车需求订单发送至服务器。
步骤405，服务器根据接收到的用车需求订单，从多个司机客户端中确定与所述用车需求订单匹配的第一目标司机客户端。
该步骤具体可以参照上述步骤102，此处不再赘述。
步骤406，服务器根据所述用车需求订单，生成派单消息，并将所述派单消息通过长连接发送至所述第一目标司机客户端。
该步骤具体可以参照上述步骤103，此处不再赘述。
步骤407，第一目标司机客户端根据接收到的派单消息，生成第一确认派单消息。
在该步骤中，若第一目标司机客户端与服务器之间的长连接可用，则第一目标司机客户端可以接收到服务器发送的派单消息，并根据接收到的派单消息，生成第一确认派单消息。
优选地，所述第一确认派单消息，是针对派单消息进行的确认操作，所述第一确认派单消息可以为：“第一目标司机客户端于××时间接收到订单号为××××××的派单消息。”
步骤408，第一目标司机客户端通过长连接将第一确认派单消息发送至服务器。
步骤409，服务器判断是否接收到所述第一确认派单消息。
在该步骤中，服务器通过判断是否接收到第一目标司机客户端返回的第一确认派单消息，来确定派单消息针对第一目标司机客户端是否发送成功。
具体的，若服务器接收到第一目标司机客户端返回的第一确认派单消息，则确定派单消息针对第一目标司机客户端发送成功；若服务器未接收到第一目标司机客户端返回的第一确认派单消息，则确定派单消息针对第一目标司机客户端发送失败。
步骤410，在服务器接收到所述第一确认派单消息时，判断所述派单消息与用车需求订单是否匹配，并将匹配结果发送至第一目标司机客户端。
在该步骤中，当服务器接收到所述第一确认派单消息时，对比派单消息中包含的第一订单号与第一确认派单消息中包含的第二订单号，判断第一订单号和第二订单号之间是否为正则匹配。若派单消息的第一订单号与第一确认派单消息的第二订单号为正则匹配，即说明第一目标司机客户端接收到的派单消息与乘客用车需求订单匹配；若派单消息的第一订单号与第一确认派单消息的第二订单号为非正则匹配，即说明第一目标司机客户端接收到的派单消息与乘客用车需求订单不匹配。
步骤411，若派单消息与用车需求订单相匹配，第一目标司机客户端通知对应的司机处理派单任务。
在该步骤中，第一目标司机客户端接收服务器发送的派单消息与用车需求订单的匹配结果，若派单消息与用车需求订单相匹配，即可认为乘客通过网约车系统成功呼叫第一目标司机客户端对应的网约车，服务器派单成功，因而，第一目标司机客户端可以通知对应的司机处理该派单任务。
若派单消息与用车需求订单不匹配，则说明第一目标司机客户端接收到的派单消息与乘客用车需求订单不匹配，即可认为乘客通过网约车系统呼叫失败第一目标司机客户端对应的网约车，服务器派单失败，第一目标司机客户端不做任何处理。
综上所述，本发明实施例提供的一种网约车方法，包括：乘客客户端生成用车需求订单，并将所述用车需求订单发送至服务器；服务器根据接收到的用车需求订单，从多个司机客户端中确定与所述用车需求订单匹配的第一目标司机客户端；服务器根据所述用车需求订单，生成派单消息，并将所述派单消息通过长连接发送至所述第一目标司机客户端；第一目标司机客户端根据接收到的派单消息，生成第一确认派单消息，并将第一确认派单消息发送至服务器；服务器判断是否接收到所述第一确认派单消息。本发明实施例中，服务器通过长连接发送派单消息和接收司机客户端返回的确认派单消息，来确认司机客户端是否接收到派单消息，从而避免了长连接受较差的网络条件限制，导致司机客户端接收不到派单消息的情况，提高了网约车接单的可靠性。
在上述实施例的基础上，本发明实施例还提供了一种服务器。
参照图6，示出了本发明实施例所述的一种服务器50的结构框图，具体可以包括如下模块：
第一接收模块501，用于接收乘客客户端发送的用车需求订单；
第一确认模块502，用于根据所述用车需求订单，从多个司机客户端中确定与所述用车需求订单匹配的第一目标司机客户端；
第一发送模块503，用于根据所述用车需求订单，生成派单消息，并将所述派单消息通过长连接发送至所述第一目标司机客户端；
第二确认模块504，用于若在第一时间阈值内接收到所述第一目标司机客户端发送的第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送成功；
第三确认模块505：用于若在所述第一时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送失败。
可选的，本发明一种服务器还包括：
第二发送模块：将所述派单消息通过长连接发送至第二目标司机客户端；所述第二目标司机客户端为所述多个司机客户端中与所述用车需求订单匹配的任意一个司机客户端，且所述第二目标司机客户端不同于所述第一目标司机客户端。
可选的，本发明一种服务器还包括：
第四确认模块：用于在第二时间阈值内接收到所述第一目标司机客户端发送的所述第一确认派单消息，以及所述第二目标司机客户端发送的第二确认派单消息时，确定接收所述第一确认派单消息的第一时间，和接收所述第二确认派单消息的第二时间，所述第二时间阈值大于所述第一时间阈值；
第五确认模块：用于若所述第一时间小于所述第二时间，则确定将所述派单消息针对所述第一目标司机客户端发送成功；
第六确认模块：用于若所述第一时间大于所述第二时间，则确定将所述派单消息针对所述第二目标司机客户端发送成功。
可选的，本发明一种网约车服务器还包括：
第七确认模块：用于在所述第二时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，但接收到了所述第二目标司机客户端发送的所述第二确认派单消息时，则确定将所述派单消息针对所述第二目标司机客户端发送成功。
可选的，本发明一种网约车服务器还包括：
第三发送模块：用于在所述第二时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，以及所述第二目标司机客户端发送的所述第二确认派单消息时，将所述派单消息通过长连接发送至第三目标司机客户端；所述第三目标司机客户端为所述多个司机客户端中与所述用车需求订单匹配的任意一个司机客户端，且所述第三目标司机客户端不同于所述第一目标司机客户端和所述第二目标司机客户端。
可选的，本发明一种网约车服务器还包括：
第二接收模块：用于接收所述乘客客户端发送的新的用车需求订单；
第四发送模块：用于若所述第一目标司机客户端与所述新的用车需求订单匹配，则根据所述新的用车需求订单，生成新的派单消息，并将所述新的派单消息通过长连接发送至所述第一目标司机客户端。
可选的，所述派单消息包括第一订单号；所述确认派单消息包括第二订单号，本发明一种服务器还包括：
第一匹配确认模块：用于若所述第一订单号和所述第二订单号之间为非正则匹配，确定所述第一目标司机客户端接收到的所述派单消息与所述用车需求订单不匹配；
第二匹配确认模块：用于若所述第一订单号和第二订单号之间为正则匹配，确定所述第一目标司机客户端接收到的所述派单消息与所述用车需求订单匹配。
可选的，本发明一种服务器还包括：
第五发送模块：用于按照预设时间周期，将所述派单消息通过长连接发送至所述第一目标司机客户端，直至接收到所述第一目标司机客户端返回的第一确认派单消息时停止；
第八确认模块：用于在接收到所述第一目标司机客户端返回的所述第一确认派单消息时，确定所述派单消息针对所述第一目标司机客户端发送成功。
可选的，本发明一种服务器，所述长连接为套接字长连接或传输控制协议长连接。
综上所述，本申请提供的一种服务器，包括：接收乘客客户端发送的用车需求订单；根据用车需求订单，从多个司机客户端中确定与用车需求订单匹配的第一目标司机客户端；根据用车需求订单，生成派单消息，并将派单消息通过长连接发送至第一目标司机客户端；若在第一时间阈值内接收到第一目标司机客户端发送的第一确认派单消息，则确定将派单消息针对第一目标司机客户端发送成功；若在第一时间阈值内未接收到第一目标司机客户端发送的第一确认派单消息，则确定将派单消息针对第一目标司机客户端发送失败。本发明实施例中，服务器通过长连接发送派单消息和接收司机客户端返回的确认派单消息，来确认司机客户端是否接收到派单消息，从而避免了长连接受较差的网络条件限制，导致司机客户端接收不到派单消息的情况，提高了网约车接单的可靠性。
在上述实施例的基础上，本发明实施例还提供了一种网约车系统。
参照图7，示出了本发明实施例所述的一种网约车系统60的结构框图，包括乘客客户端601、服务器602和司机客户端603。
其中，乘客客户端601用于发送用车需求订单至服务器602；
服务器602用于接收乘客客户端601发送的用车需求订单，并根据用车需求订单，从多个司机客户端603中确定与用车需求订单匹配的第一目标司机客户端；以及根据用车需求订单，生成派单消息，并将派单消息通过长连接发送至第一目标司机客户端；若在第一时间阈值内接收到第一目标司机客户端发送的第一确认派单消息，则确定将派单消息针对第一目标司机客户端发送成功；若在第一时间阈值内未接收到第一目标司机客户端发送的第一确认派单消息，则确定将派单消息针对第一目标司机客户端发送失败；
司机客户端603用于接收服务器602发送的派单消息，若接收到派单消息，则发送第一确认派单消息至服务器602。
综上所述，本申请提供的一种网约车系统，包括：接收乘客客户端发送的用车需求订单；根据用车需求订单，从多个司机客户端中确定与用车需求订单匹配的第一目标司机客户端；根据用车需求订单，生成派单消息，并将派单消息通过长连接发送至第一目标司机客户端；若在第一时间阈值内接收到第一目标司机客户端发送的第一确认派单消息，则确定将派单消息针对第一目标司机客户端发送成功；若在第一时间阈值内未接收到第一目标司机客户端发送的第一确认派单消息，则确定将派单消息针对第一目标司机客户端发送失败。本发明实施例中，服务器通过长连接发送派单消息和接收司机客户端返回的确认派单消息，来确认司机客户端是否接收到派单消息，从而避免了长连接受较差的网络条件限制，导致司机客户端接收不到派单消息的情况，提高了网约车接单的可靠性。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明的保护范围之内。
以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (11)

1.一种网约车方法，其特征在于，包括：
接收乘客客户端发送的用车需求订单；
根据所述用车需求订单，从多个司机客户端中确定与所述用车需求订单匹配的第一目标司机客户端；
根据所述用车需求订单，生成派单消息，并将所述派单消息通过长连接发送至所述第一目标司机客户端；
若在第一时间阈值内接收到所述第一目标司机客户端发送的第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送成功；
若在所述第一时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送失败。
2.根据权利要求1所述的方法，其特征在于，在所述若在所述第一时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息时，则确定将所述派单消息针对所述第一目标司机客户端发送失败的步骤之后，所述方法还包括：
将所述派单消息通过所述长连接发送至第二目标司机客户端；所述第二目标司机客户端为所述多个司机客户端中与所述用车需求订单匹配的任意一个司机客户端，且所述第二目标司机客户端不同于所述第一目标司机客户端。
3.根据权利要求2所述的方法，其特征在于，在所述将所述派单消息通过所述长连接发送至第二目标司机客户端的步骤之后，所述方法还包括：
当在第二时间阈值内接收到所述第一目标司机客户端发送的所述第一确认派单消息，以及所述第二目标司机客户端发送的第二确认派单消息时，确定接收所述第一确认派单消息的第一时间，和接收所述第二确认派单消息的第二时间，所述第二时间阈值大于所述第一时间阈值；
若所述第一时间小于所述第二时间，则确定将所述派单消息针对所述第一目标司机客户端发送成功；
若所述第一时间大于所述第二时间，则确定将所述派单消息针对所述第二目标司机客户端发送成功。
4.根据权利要求2所述的方法，其特征在于，在所述将所述派单消息通过所述长连接发送至第二目标司机客户端的步骤之后，所述方法还包括：
当在第二时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，但接收到了所述第二目标司机客户端发送的所述第二确认派单消息时，则确定将所述派单消息针对所述第二目标司机客户端发送成功。
5.根据权利要求2所述的方法，其特征在于，在所述将所述派单消息通过所述长连接发送至第二目标司机客户端的步骤之后，所述方法还包括：
当在第二时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，以及所述第二目标司机客户端发送的所述第二确认派单消息时，将所述派单消息通过所述长连接发送至第三目标司机客户端；所述第三目标司机客户端为所述多个司机客户端中与所述用车需求订单匹配的任意一个司机客户端，且所述第三目标司机客户端不同于所述第一目标司机客户端和所述第二目标司机客户端。
6.根据权利要求1所述的方法，其特征在于，在所述若在所述第一时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息时，则确定将所述派单消息针对所述第一目标司机客户端发送失败的步骤之后，所述方法还包括：
接收所述乘客客户端发送的新的用车需求订单；
若所述第一目标司机客户端与所述新的用车需求订单匹配，则根据所述新的用车需求订单，生成新的派单消息，并将所述新的派单消息通过所述长连接发送至所述第一目标司机客户端。
7.根据权利要求1所述的方法，其特征在于，所述派单消息包括第一订单号；所述第一确认派单消息包括第二订单号，在所述若在所述第一时间阈值内接收到所述第一目标司机客户端发送的第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送成功的步骤之后，所述方法还包括：
若所述第一订单号和所述第二订单号之间为非正则匹配，则确定所述第一目标司机客户端接收到的所述派单消息与所述用车需求订单不匹配；
若所述第一订单号和第二订单号之间为正则匹配，则确定所述第一目标司机客户端接收到的所述派单消息与所述用车需求订单匹配。
8.根据权利要求1所述的方法，其特征在于，在所述根据所述用车需求订单，生成派单消息之后，所述方法还包括：
按照预设时间周期，将所述派单消息通过所述长连接发送至所述第一目标司机客户端，直至接收到所述第一目标司机客户端返回的第一确认派单消息时停止；
在接收到所述第一目标司机客户端返回的所述第一确认派单消息时，确定所述派单消息针对所述第一目标司机客户端发送成功。
9.根据权利要求1-8任一项所述的方法，其特征在于，所述长连接为套接字长连接或传输控制协议长连接。
10.一种服务器，其特征在于，所述服务器包括：
第一接收模块：用于接收乘客客户端发送的用车需求订单；
第一确认模块：用于根据所述用车需求订单，从多个司机客户端中确定与所述用车需求订单匹配的第一目标司机客户端；
第一发送模块：用于根据所述用车需求订单，生成派单消息，并将所述派单消息通过长连接发送至所述第一目标司机客户端；
第二确认模块：用于若在第一时间阈值内接收到所述第一目标司机客户端发送的第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送成功；
第三确认模块：用于若在所述第一时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送失败。
11.一种网约车系统，其特征在于，所述系统包括：乘客客户端、司机客户端和服务器；
其中，所述乘客客户端用于发送用车需求订单至服务器；
所述服务器用于接收所述乘客客户端发送的所述用车需求订单，并根据所述用车需求订单，从多个所述司机客户端中确定与所述用车需求订单匹配的第一目标司机客户端；以及根据所述用车需求订单，生成派单消息，并将所述派单消息通过长连接发送至所述第一目标司机客户端；若在第一时间阈值内接收到所述第一目标司机客户端发送的第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送成功；若在所述第一时间阈值内未接收到所述第一目标司机客户端发送的所述第一确认派单消息，则确定将所述派单消息针对所述第一目标司机客户端发送失败；
所述司机客户端用于接收所述服务器发送的所述派单消息，若接收到所述派单消息，则发送所述第一确认派单消息至所述服务器。
CN201910780577.1A 2019-08-22 2019-08-22 一种网约车方法及系统 Pending CN110533312A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910780577.1A CN110533312A (zh) 2019-08-22 2019-08-22 一种网约车方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910780577.1A CN110533312A (zh) 2019-08-22 2019-08-22 一种网约车方法及系统

Publications (1)

Publication Number Publication Date
CN110533312A true CN110533312A (zh) 2019-12-03

Family

ID=68662613

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910780577.1A Pending CN110533312A (zh) 2019-08-22 2019-08-22 一种网约车方法及系统

Country Status (1)

Country Link
CN (1) CN110533312A (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112184387A (zh) * 2020-10-12 2021-01-05 广州宸祺出行科技有限公司 一种保证司机状态和订单状态变化一致性的方法和系统
CN113112116A (zh) * 2021-03-10 2021-07-13 摩拜(北京)信息技术有限公司 订单分配方法、装置及服务器
CN113139726A (zh) * 2021-04-23 2021-07-20 北京白龙马云行科技有限公司 多租户派单方法和网约车系统
CN113762556A (zh) * 2021-09-17 2021-12-07 江西易至智行汽车运营服务有限公司 基于叫车桩的约车方法、系统、存储介质及计算机设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103648085A (zh) * 2013-12-11 2014-03-19 五八同城信息技术有限公司 一种克服网络抖动的移动终端消息传递方法
CN106254464A (zh) * 2016-08-07 2016-12-21 深圳市小马立行科技有限公司 一种车载智能终端及其网络通信方法
CN108694452A (zh) * 2017-04-06 2018-10-23 北京嘀嘀无限科技发展有限公司 车载接单方法及装置、服务器、车载系统、车辆
CN108765072A (zh) * 2018-05-23 2018-11-06 杭州优行科技有限公司 车辆共享方法、装置及电子设备
CN108805411A (zh) * 2018-05-18 2018-11-13 北京嘀嘀无限科技发展有限公司 网约车订单分配方法、装置、服务器、终端和可读存储介质
CN109034428A (zh) * 2018-05-29 2018-12-18 梅州蜂派网络科技有限公司 网络约车方法及存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103648085A (zh) * 2013-12-11 2014-03-19 五八同城信息技术有限公司 一种克服网络抖动的移动终端消息传递方法
CN106254464A (zh) * 2016-08-07 2016-12-21 深圳市小马立行科技有限公司 一种车载智能终端及其网络通信方法
CN108694452A (zh) * 2017-04-06 2018-10-23 北京嘀嘀无限科技发展有限公司 车载接单方法及装置、服务器、车载系统、车辆
CN108805411A (zh) * 2018-05-18 2018-11-13 北京嘀嘀无限科技发展有限公司 网约车订单分配方法、装置、服务器、终端和可读存储介质
CN108765072A (zh) * 2018-05-23 2018-11-06 杭州优行科技有限公司 车辆共享方法、装置及电子设备
CN109034428A (zh) * 2018-05-29 2018-12-18 梅州蜂派网络科技有限公司 网络约车方法及存储介质

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112184387A (zh) * 2020-10-12 2021-01-05 广州宸祺出行科技有限公司 一种保证司机状态和订单状态变化一致性的方法和系统
CN113112116A (zh) * 2021-03-10 2021-07-13 摩拜(北京)信息技术有限公司 订单分配方法、装置及服务器
CN113112116B (zh) * 2021-03-10 2024-04-16 摩拜(北京)信息技术有限公司 订单分配方法、装置及服务器
CN113139726A (zh) * 2021-04-23 2021-07-20 北京白龙马云行科技有限公司 多租户派单方法和网约车系统
CN113762556A (zh) * 2021-09-17 2021-12-07 江西易至智行汽车运营服务有限公司 基于叫车桩的约车方法、系统、存储介质及计算机设备

Similar Documents

Publication Publication Date Title
CN110533312A (zh) 一种网约车方法及系统
CN106850580B (zh) 一种汽车账号系统及账号自动验证方法
US10027805B2 (en) Connection management for a vehicle telematics unit
CN110217132A (zh) 充电控制方法、装置、计算机设备及其存储介质
EP1575218A2 (en) System for transmitting and receiving data from within a mobile unit without a constant connection to a communication network
US20140378055A1 (en) Pairing a wireless devices within a vehicle
CN102571885B (zh) 车载信息推送服务系统和方法
WO2017067150A1 (zh) 车辆操作控制方法、相关设备和系统
CN107977215B (zh) 车载系统升级方法及装置
CN102571877B (zh) 车载信息同步服务系统和方法
CN107945406B (zh) 车辆管理方法及应用服务器
CN110027507B (zh) 一种共享汽车的多维度车锁状态切换方法及系统
CN111459149A (zh) 一种智能车辆编队行驶方法、装置及系统
US20200334588A1 (en) Method for updating an availability indicator of a vehicle for reserving same
EP1544744A1 (en) Terminal authentication system, terminal authentication method, and terminal authentication server
CN107835529B (zh) 天基骨干网动态接入系统、节点、管理中心及方法
CN107104805B (zh) 对使用蜂窝通信协议的无线装置进行开通的方法
CN105978796A (zh) 基于不稳定移动网络的消息通信方法及系统
CN111698795A (zh) 对分组交换域失败的电路交换域响应
CN107040289B (zh) 基于近距离通讯的信息传输方法及其装置
CN202004788U (zh) 车载信息推送服务系统
CN103685398A (zh) 通信连接建立方法及通信系统
CN116846959A (zh) 一种基于mqtt协议的消息收发方法及装置
CN101860804B (zh) 预定义加入群组会话的加入实现方法和系统
CN103312753A (zh) 一种物联网通信方法和装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20191203